Our security auditor is an idiot. How do I give him the information he wants? (Server Fault)
-
Just... read the OP.
Representative quote from the security "expert":
As explained, this information should be easily available on any well maintained system to any competent administrator. Your failure to be able to provide this information leads me to believe you are aware of security flaws in your system and are not prepared to reveal them. Our requests line up with the PCI guidelines and both can be met. Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use.
-
Saw this the other day on Reddit. Pretty funny.
I read in detail through those responses and your original post, the responders all need to get their facts right. I have been in this industry longer than anyone on that site, getting a list of user account passwords is incredibly basic, it should be one of the first things you do when learning how to secure your system and is essential to the operation of any secure server
I R BETTAR THAN THOS PEPOL! IF YUO CANT SEE PASSWRODS HOW U NO THEY SEKUR!
-
Our requests line up with the PCI guidelines
https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf - Requirement 8 (page 19).
Also, as I was trying to find that, I came across another gem. Is the expert's name T. Rob, or are there more of these people running around?
the PCI Data Security Standard (PCI-DSS) requires passwords to be encrypted. Although this sounds good on its face, the standard fails to account for the bi-lateral nature of passwords. As a result, assessments are more complex and expensive and the systems assessed often less secure because of it, not more.
-
@blek said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
the bi-lateral nature of passwords
Is this something like the sound accelerometers in the Apple thread?
-
@boomzilla Either that or something involving
-
@blek said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
T. Rob https://t-rob.net/2013/02/17/its-time-for-sensible-password-security-standards-in-the-pci-dss/
No WTF in this article.
The article you link to distinguishes between:
- "inbound" passwords which the user sends to the system to authenticate - these are one-way-hashed
- "outbound" passwords which the system uses to access some other system - for example a DB password in the application server
He rightly says the outbound password can not be one-way-hashed and remain useful. The discussed standard says that all passwords must be encrypted, so to follow the standard people use reversible encryption of the outbound passwords, which is useless in that context - the plaintext must be recreated by the program anyway.
So he suggests to fix the standard to better accommodate the case of outbound passwords.
-
@dkf Oh, no. I read farther along. He's talking about two cases where your system handles passwords:
- as authentication mechanisms for your users
- as your system's authentication mechanism for accessing an external system
So, that makes sense. Bi-lateral as in, are you entering a password to authenticate or are you testing an entered password for authentication. But apparently the standard doesn't discriminate against these two. One of those cases, you need to be able to recover the plain text. One you shouldn't.
-
Why has this old SO post been making the rounds recently? It's from 2011!
-
I saw this a couple years ago, it's one of my favorite gems from server fault. Just astounding XD
-
@Adynathos said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
The article you link to distinguishes between:
- "inbound" passwords which the user sends to the system to authenticate - these are one-way-hashed
- "outbound" passwords which the system uses to access some other system - for example a DB password in the application server
That's the difference between the identities asserted by users and the identities asserted by the system itself. While the system might make assertions about users identities (and the operations that it is seeking to perform on their behalf) it shouldn't assert that it is the user. (Nor should any user assert that they are the system, of course.)
-
Full disclosure: one of the sysadmin passwords is the year and make it an old popular vehicle. All lowercase no spaces.
-
I think this guy was trying to collect all the users' credentials just to ensure
his own financialsecurity.
-
@cartman82 Hey hey, this was posted 5 years ago. Technology improves at, like, the speed of light or something so maybe in 2011 that IS what strong cryptography meant.
Joking aside, what I'd really like to know is how we still have some companies not encrypting user passwords, or encrypting them badly with MD5. This was old news in 2011 but it's still happening!
-
@aapis said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
encrypting
@aapis said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
MD5
twitch
-
@error said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@aapis said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
encrypting
@aapis said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
MD5
twitch
I wasn't gonna point that out, but... Yeah.
-
@aapis said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
or encrypting them badly with MD5.
I assume you mean hashing without a salt? MD5 gets a lot of hate these days, but I don't see how a salted hash is going to get beaten without testing most or all of the sample space of passwords. Geometric lockout takes care of external attacks, and if you're worried that they'll download a copy of your database and brute force the passwords offline, they've already got your data anyway.
-
@Adynathos said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
He rightly says the outbound password can not be one-way-hashed and remain useful.
Obviously you just change the database password to its hash. This way you can securely pass the hash around and never reveal the real password! All secured!
-
!!!LIE!!!
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@aapis said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
or encrypting them badly with MD5.
I assume you mean hashing without a salt? MD5 gets a lot of hate these days, but I don't see how a salted hash is going to get beaten without testing most or all of the sample space of passwords. Geometric lockout takes care of external attacks, and if you're worried that they'll download a copy of your database and brute force the passwords offline, they've already got your data anyway.
The problem with MD5 is that it's fast and doesn't consume much memory. As a result, a bruteforce search is easily doable using a GPU and some time, with dictionary attacks immensely decreasing the time to crack.
So they might have your database, but now owning information about the password may allow the attacker to test those passwords on more important sites (your email account, for example).
-
@JBert said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
The problem with MD5 is that it's fast and doesn't consume much memory. As a result, a bruteforce search is easily doable using a GPU and some time, with dictionary attacks immensely decreasing the time to crack.
Right, and using something like bcrypt comes with its own set of tradeoffs. If your site has thousands of concurrent users, scaling the work factor on a login to take a significant fraction of a second becomes a problem. Crypto is probably unique in being the only domain where something that's less efficient is superior.
So they might have your database, but now owning information about the password may allow the attacker to test those passwords on more important sites (your email account, for example).
I can see value in protecting dumbass users, but that issue would be the fault of dumbass users for using the same password on multiple sites.
-
The more I read about the idea of doing the salting/hashing on the client side, the more I like it.
-
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
The more I read about the idea of doing the salting/hashing on the client side, the more I like it.
It needs a totally different algorithm, since you can't really trust the client to only run code that you control.
-
@dkf said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
The more I read about the idea of doing the salting/hashing on the client side, the more I like it.
It needs a totally different algorithm, since you can't really trust the client to only run code that you control.
that, and it's not really all that different from a password, except now the password is the one salted and hashed on the client, which you then need to deal with on the server (possiubly by oversalting and rehashing)
advantage:
- you never see the password ever
disadvantage:
- you can never change the client to use a different hash/salt method without needing mass password resets (okay, you still can't server side, but there are ways to handle that server side and with server side the external attacker can't know what your hash strat is.
-
@dkf said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
The more I read about the idea of doing the salting/hashing on the client side, the more I like it.
It needs a totally different algorithm, since you can't really trust the client to only run code that you control.
You can have separate logic for register and login: Send the password to the server when registering, and hash on the client side for login. That way, you don't need to trust anyone
@accalia said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
that, and it's not really all that different from a password
It's not, and it doesn't make a difference either way
@accalia said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
except now the password is the one salted and hashed on the client, which you then need to deal with on the server (possiubly by oversalting and rehashing)
The point of salting/hashing is to prevent retrieving the password. Rehashing doesn't help with that
@accalia said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
- you can never change the client to use a different hash/salt method without needing mass password resets (okay, you still can't server side, but there are ways to handle that server side and with server side the external attacker can't know what your hash strat is.
You can change it pretty much exactly as you do on the server side: When you want to change the hash algorithm, just change the JS to do both hashes and send it to the server, and adopt the new one if the old one matches. You have the old hashed password, so you know which password is hashed with what algorithm.
-
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
You can change it pretty much exactly as you do on the server side: When you want to change the hash algorithm, just change the JS to do both hashes and send it to the server, and adopt the new one if the old one matches. You have the old hashed password, so you know which password is hashed with what algorithm.
okay, but now you have to salt twice on the client forever, because you need to support the old hans until everyone has logged in with the new hash generation.
either that or you need to eventually cut off the old hash and force those people who log in once every two years to reset their passwords because you threw away the way you had to authenticate them.
-
@accalia said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
okay, but now you have to salt twice on the client forever, because you need to support the old hans until everyone has logged in with the new hash generation.
You can avoid this by splitting the username and password entry into 2 steps:
- Client sends you username only
- You send back salt and hash algorithm(s)
- Client sends back hash(es)
Logging in to a Google account already requires 2 steps, and I don't find that inconvenient at all
-
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
You send back salt and hash algorithm(s)
Client sends back hash(es)What advantage does that give you over using SSL?
-
@Yamikuronue said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
You send back salt and hash algorithm(s)
Client sends back hash(es)What advantage does that give you over using SSL?
Security-wise, nothing. You'd need to use SSL for client side hashing anyway since the hash is effectively your password for this site.
The point of this is to offload the hashing workload to the client. I remember reading somewhere on this forum that someone used to use the entire text from a book for their password. This would prevent it from chewing up too much server resources
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
Right, and using something like bcrypt comes with its own set of tradeoffs. If your site has thousands of concurrent users, scaling the work factor on a login to take a significant fraction of a second becomes a problem
You're missing one of the main problems with MD5, which is that it's only 128-bit, meaning you can literally do things like generate all the possible hashes and compare them against the hash you're trying to crack. https://en.wikipedia.org/wiki/MD5#Security. The algorithm also has vulnerabilities but that just compounds an already devestating problem.
-
@pydsigner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
Right, and using something like bcrypt comes with its own set of tradeoffs. If your site has thousands of concurrent users, scaling the work factor on a login to take a significant fraction of a second becomes a problem
You're missing one of the main problems with MD5, which is that it's only 128-bit, meaning you can literally do things like generate all the possible hashes and compare them against the hash you're trying to crack. https://en.wikipedia.org/wiki/MD5#Security. The algorithm also has vulnerabilities but that just compounds an already devestating problem.
How are you going to try all possible combinations when there's a geometric lockout scheme in place?
If the attacker has access to the backend, you're already done for, and the only thing a different hashing scheme would accomplish would be to protect idiot users who use the same password everywhere.
-
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@accalia said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
that, and it's not really all that different from a password
It's not, and it doesn't make a difference either way
Why bother hashing at all? If you have a breach the attackers have what they need to login to an account. Yeah, sure, they'll have to bypass your hashing code. That still seems a lot easier than having to crack salted hashed passwords.
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
If the attacker has access to the backend, you're already done for, and the only thing a different hashing scheme would accomplish would be to protect idiot users who use the same password everywhere.
It's entirely possible to gain read-only access to db with or without having breached the backend itself. And I'm a bit confused now; do you even believe in hashing passwords? You can say "people shouldn't reuse passwords" to defend that one too, but in a world where it's reported that 13% of people are using passwords from the top 1000 most common list, expecting people not to be dumb with their passwords is shortsighted by far.
-
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
I remember reading somewhere on this forum that someone used to use the entire text from a book for their password. This would prevent it from chewing up too much server resources
Wow, that's... that's... wow.
A coworker of mine told me about a password he used to use. It's the first couple lines of a poem, in Spanish. No one's gonna guess that! But a whole book? That's really going above and beyond.
-
@cark said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
The point of this is to offload the hashing workload to the client. I remember reading somewhere on this forum that someone used to use the entire text from a book for their password. This would prevent it from chewing up too much server resources
yeah, that was me. i did it on meta.discourse to prove a point really. (i never logged into the account after the point was made)
naturally atwood missed my point entirely and now (assuming it hasn't been bikeshedded away) discourse now silently truncates passwords longer than a certain number of characters (400 IIRC), meaning that even if my example account hadn't been banned i couldn't have logged into it anyway as the stored password was still the entire contents of the gutenberg press edition of war and peace, and the password i could send was only the first 400 characters.
my current password is a much more reasonable 95+/-10 character passphrase.
-
@pydsigner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
It's entirely possible to gain read-only access to db with or without having breached the backend itself.
Sure, if there's an SQLi vulnerability. But again, at that point, they've already got all your data anyway.
And I'm a bit confused now; do you even believe in hashing passwords?
Of course I do. I'm just questioning the value of upping the work factor to make the crypto nerds happy when one might be working with a real-time system (e.g. a game server) where taking even 1ms to process a single login when dealing with hundreds or thousands of users will have a significant impact.
You can say "people shouldn't reuse passwords" to defend that one too, but in a world where it's reported that 13% of people are using passwords from the top 1000 most common list, expecting people not to be dumb with their passwords is shortsighted by far.
Maybe the password is an outdated and cumbersome instrument that should be phased out? Maybe we need more two-factor? Maybe those people need to learn some hard lessons?
Again, I accept there's value in protecting idiots, but I would rather devote resources to prevent attackers from even getting into my database. I've worked on systems that stored names, phone numbers, birthdays, addresses, and in some cases, SSNs. That sort of information is far more valuable to an attacker than brute-forcing a password which may or may not work elsewhere.
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
where taking even 1ms to process a single login when dealing with hundreds or thousands of users will have a significant impact.
Are all thousands of (legitimate) users constantly logging in every second? because there would be a nice TRWTF there if I ever saw one...
Edit: And even then, geometric lockout.
-
@accalia said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
either that or you need to eventually cut off the old hash and force those people who log in once every two years to reset their passwords because you threw away the way you had to authenticate them.
Probably do this anyway, even if the hashing is done on the server. Just wait {x} months, then wipe out all the old password hashes along with the old hash algorithm, and trigger a "Because you have not logged in for more than {x} months, your account has been temporarily deactivated. Please reset your password to reactivate it." message for the users who now have no password.
-
@Tsaukpaetra said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
Are all thousands of (legitimate) users constantly logging in every second? because there would be a nice TRWTF there if I ever saw one...
Of course! How else do you think I can afford to adorn my apartment with large, decorative, but still functional Bags O' Money?
Edit: And even then, geometric lockout.
All I'm saying is that there are cases where the crypto method of being slow and complex are at odds with other requirements, and that security is about balancing threats and countermeasures using the finite resources at your disposal.
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
at odds with other requirements
Such as only needing to do it once per user for a session?
-
@pydsigner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
expecting people not to be dumb
with their passwordsis shortsighted by far.FTFY
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
All I'm saying is that there are cases where the crypto method of being slow and complex are at odds with other requirements, and that security is about balancing threats and countermeasures using the finite resources at your disposal.
As they say, security is easy. It's letting people in that's the difficult part!
-
@cartman82 said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
Strong cryptography only means the passwords must be encrypted while the user is inputting them
I always hash my passwords as I'm typing them in.
It takes me a while to figure out the hash, though. I go through a lot of paper.
-
@Lorne-Kates is that because FF22 couldn't do it in JavaScript for you?
-
@Tsaukpaetra said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
at odds with other requirements
Such as only needing to do it once per user for a session?
No, the requirement that you stay under 16ms per frame, in the example of a game server.
Granted, you could move the login processing to a worker thread that calls back with a login result... until the queue piles up. Then, you might consider having a dedicated login server, but I'd hope one wouldn't need that until around 107 users.
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
No, the requirement that you stay under 16ms per frame, in the example of a game server.
Again, LOGGING IN EVERY 16 MS IS
-
@error Peak pedantry reached.
-
@aapis It's all downhill from here.
I did, it guys. @mikeTheLiar is no longer the worst of the worst. I've taken the throne.
-
@masonwheeler said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
All I'm saying is that there are cases where the crypto method of being slow and complex are at odds with other requirements, and that security is about balancing threats and countermeasures using the finite resources at your disposal.
As they say, security is easy. It's letting people in that's the difficult part!
Letting people in is also easy. It's letting the right people in that's the difficult part!
-
@Tsaukpaetra said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
No, the requirement that you stay under 16ms per frame, in the example of a game server.
Again, LOGGING IN EVERY 16 MS IS
Having 216000 people log in during an hour would be sufficient to meet this condition. That's less than what Steam handles between, say, 2AM and 4AM.
Edit: math fail, confusing frames for seconds.
-
@Groaner said in Our security auditor is an idiot. How do I give him the information he wants? (Server Fault):
what Steam handles between, say, 2AM and 4AM
...in which time zone?