5 ms·

Most people are arguing that a password shouldn't ever be recoverable and that "even root level access should not grant you passwords". This feels like shaky l

Most people are arguing that a password shouldn't ever be recoverable and that "even root level access should not grant you passwords". This feels like shaky logic though. Hashing is a good defence against DB harvesting but it doesn't stop a root level admin from listening to inbound unencrypted logins. Prolonged root access is therefore still a viable attack vector. The question is only how quickly you can harvest those passwords. Other people are arguing that with sufficient decoupling and safeguards between the encryption key and the database there is an acceptable risk associated with storing a password. Since services like Yodlee clearly do store passwords this is something that companies do address. Could someone who really knows this area well please describe how this is done in a way to minimise risk and how the risk compares to a traditional 1-way hashing?

pingswept 15y ago
> Hashing is a good defence against DB harvesting but it doesn't stop a root level admin from listening to inbound unencrypted logins. Forgive my ignorance of web authentication, but aren't passwords hashed in the browser before being sent to the server for authentication? If not, why? It seems to me that it would be just as easy to hash on the browser side as on the server side, but passwords are less exposed if you do it on the browser side. (Apologies for hijacking your thread, but I'm interested in the technical details here.)
- lt 15y ago
  The point of hashing is from the difficulty of reversing it; generating a string that when hashed matches that value should be difficult. That way, even if someone has access to the hashes, he is unable to login - he needs the password. If you accept the hash from the client, anyone having the hash is able to login, making hashing pointless.
  - mikeash 15y ago
    It's not hard to fix that. You have the server send the client a random salt each time. The client then sends back a hash computed with that salt, and the server doesn't accept the same salt more than once. Done right, the server never sees your plaintext password and replay attacks still fail.
    - lt 15y ago
      I don't see how that can work. What would the server compare the received salted hash with, if it has never seen the plaintext?
      - mikeash 15y ago
        You do a double hash. Basically, toSend = hash(salt + hash(password)). The server stores hash(password), not password.
        kbolino 15y ago
        The difference between hmac(salt,hash(password)) and hash(password) is trivial when the salt is known. It doesn't matter that the server only accepts the salt once, if the server is willing to produce another salt for the next attempt. If the server limits the number of salts it will produce in a given timeframe, it might as well limit the number of attempts to begin with, and so there's no point in "double hashing."
        mikeash 15y ago
        The goal, I believe, is to prevent recovery of the plaintext password so that it can't be used to gain access to other accounts with the same password. The double hash prevents an attacker from ever obtaining that plaintext password.
        kbolino 15y ago
        The issue was, I believe, in preventing a remote attacker who knows the hash from using it to authenticate[1]. That is why passwords are transmitted in plaintext then hashed and validated on the server side. You should never trust the client to perform your cryptography for you, because you have no idea who--or what--the client is. No amount of obfuscation can alleviate that fact. 1 http://news.ycombinator.com/item?id=3419700 http://news.ycombinator.com/item?id=3419700
- mrkurt 15y ago
  Passwords are rarely hashed client side. It doesn't matter, though, if you have enough control over a server to listen to POSTs for unhashed passwords, you probably have enough to inject some script and capture them on the client side.
  - pingswept 15y ago
    True, but then you have to mimic the form submission without alerting the user. It's certainly possible, but much less feasible compared to just passive logging of all POSTs that have a field called [password|pw|pass|passwd]. I guess if you're targeting a single site the difference is small.
    - simonbrown 15y ago
      It would be just slightly more complicated to inject a script that POSTs back anything typed into a password field. Hashing passwords client-side would just provide a false sense of security. Surely if it's worth doing it, it would be worth the cost of an SSL certificate and the overhead of protecting (a minimum of) all pages and requests handling passwords?
      - soumyadeb 15y ago
        I guess, client side hashing is not used because some users disable javascript. Can't leave them out :)
  - tomp 15y ago
    Not even that. You simply have to delete the JavaScript that hashes them on the client side, and have the browser send them unhashed (which is the default behaviour of HTML forms).
jedbrown 15y ago
How do people try to justify storing passwords in recoverable form? So that they can remind users of the old password. How do they actually send the reminder? By email. But email is not secure, you should always assume that someone is eavesdropping on your email. Far too many users reuse a password from one service on others, so sending a password in email is a huge violation of trust.
- tomp 15y ago
  Storing passwords in plain text (or using an encryption method) and sending password over email are two distinct issues. I think storing passwords (and not only hashes of passwords) might be a good idea if it is harder for the attacker to recover the passwords than to gain root access to the http/database server, however, I would NEVER send passwords in emails (not even newly generated passwords). A simple solution is to send a one-time login link, and have the password displayed in the browser, over a https:// https:// connection. There is still a small possibility of stealing the password (someone intercepts the email and clicks on the link before the legitimate user does), but at least the user would become aware of it (his link wouldn't work any more).
  - jedbrown 15y ago
    One issue is that even if the password database is more secure than root access on the server, having the database at all means that it's possible to steal the entire thing in a small amount of time and in a way that may be difficult to detect. An attacker with root access on the server would have to keep the exploit open to continue gathering user credentials. And I still don't see what convenience having the password database offers. One-time links are definitely the right way, though I think it's better to give the user a new password dialog than to tell them a randomly generated password.
  - deleted 15y ago
    [deleted]
brudgers 15y ago
[Not answering the questions] What I find interesting about the debate regarding password storage ethics is the question, "What is a website's ethical responsibility in regards to a user's password?" On the face of it, one could argue that the extent of a site's ethical responsibility ends at their IP address -- i.e. a site is only responsible for protecting one's password to the extent that it reasonably protects the user from harm resulting from someone else using their credentials on the site. For example, under this scenario, HN's responsibility would be to take reasonable steps to protect my password in accordance with the level of harm I would experience should my account be compromised. HN's "reasonable steps" are different from those of Bank of America, and emailing my password in plaintext would not shock me (even if unlikely). However, there is a tendency for people to argue that the extent of a site's ethical responsibility is to protect the user from harm elsewhere on the internet - the logic of course being that many people use the same password for HN and BOA. In some sense, this argument is premised on websites having some level responsibility for general welfare of their users (i.e. a website's responsibility towards users extends across the entire internet to some degree). A weakness of that argument is that once general welfare of the user is the standard, plaintext storage of a password may promote the user's general welfare to a greater extent than more secure measures - security is just one criteria in regards to utility. A house with few windows is usually more secure but often less healthy for its occupants. Although technical considerations are important, the issues surrounding password security methods for most sites are social: trivial passwords, password reuse, and "lost" passwords. Holding all sites to the standards which apply to sites with fiduciary responsibility such as banks or corporate IT centers is, in my opinion, somewhat asinine. Every web service does not need to be locked down, and good architecture will balance security with commodity and delight.
jtchang 15y ago
For the vast majority of sites storing passwords in the clear is a bad idea. However sometimes you need to store sensitive data. Generally this is done with hardware security modules which rotate encryption keys in a periodic basis. Access to the sensitive data is also audited. Risk can be minimized. It just comes down to if it is worth if for your business. PCI DSS is just one example of minimizing risk.
- ajross 15y ago
  Uh... the code in question is retrieving those passwords and emailing them over unencrypted SMTP. How is that design improved by the use of key rotation or "hardware security modules"?
  - jtchang 15y ago
    By using a HSM you store the encryption key on a separate hardware device. I am already assuming that if you want to implement something like this you will encrypt the passwords. Thus the problem is knowing where to put the keys.

pingswept 15y ago

> Hashing is a good defence against DB harvesting but it doesn't stop a root level admin from listening to inbound unencrypted logins. Forgive my ignorance of web authentication, but aren't passwords hashed in the browser before being sent to the server for authentication? If not, why? It seems to me that it would be just as easy to hash on the browser side as on the server side, but passwords are less exposed if you do it on the browser side. (Apologies for hijacking your thread, but I'm interested in the technical details here.)

lt 15y ago
The point of hashing is from the difficulty of reversing it; generating a string that when hashed matches that value should be difficult. That way, even if someone has access to the hashes, he is unable to login - he needs the password. If you accept the hash from the client, anyone having the hash is able to login, making hashing pointless.
- mikeash 15y ago
  It's not hard to fix that. You have the server send the client a random salt each time. The client then sends back a hash computed with that salt, and the server doesn't accept the same salt more than once. Done right, the server never sees your plaintext password and replay attacks still fail.
  - lt 15y ago
    I don't see how that can work. What would the server compare the received salted hash with, if it has never seen the plaintext?
    - mikeash 15y ago
      You do a double hash. Basically, toSend = hash(salt + hash(password)). The server stores hash(password), not password.
      - kbolino 15y ago
        The difference between hmac(salt,hash(password)) and hash(password) is trivial when the salt is known. It doesn't matter that the server only accepts the salt once, if the server is willing to produce another salt for the next attempt. If the server limits the number of salts it will produce in a given timeframe, it might as well limit the number of attempts to begin with, and so there's no point in "double hashing."
        mikeash 15y ago
        The goal, I believe, is to prevent recovery of the plaintext password so that it can't be used to gain access to other accounts with the same password. The double hash prevents an attacker from ever obtaining that plaintext password.
        kbolino 15y ago
        The issue was, I believe, in preventing a remote attacker who knows the hash from using it to authenticate[1]. That is why passwords are transmitted in plaintext then hashed and validated on the server side. You should never trust the client to perform your cryptography for you, because you have no idea who--or what--the client is. No amount of obfuscation can alleviate that fact. 1 http://news.ycombinator.com/item?id=3419700 http://news.ycombinator.com/item?id=3419700
mrkurt 15y ago
Passwords are rarely hashed client side. It doesn't matter, though, if you have enough control over a server to listen to POSTs for unhashed passwords, you probably have enough to inject some script and capture them on the client side.
- pingswept 15y ago
  True, but then you have to mimic the form submission without alerting the user. It's certainly possible, but much less feasible compared to just passive logging of all POSTs that have a field called [password|pw|pass|passwd]. I guess if you're targeting a single site the difference is small.
  - simonbrown 15y ago
    It would be just slightly more complicated to inject a script that POSTs back anything typed into a password field. Hashing passwords client-side would just provide a false sense of security. Surely if it's worth doing it, it would be worth the cost of an SSL certificate and the overhead of protecting (a minimum of) all pages and requests handling passwords?
    - soumyadeb 15y ago
      I guess, client side hashing is not used because some users disable javascript. Can't leave them out :)
- tomp 15y ago
  Not even that. You simply have to delete the JavaScript that hashes them on the client side, and have the browser send them unhashed (which is the default behaviour of HTML forms).

jedbrown 15y ago

How do people try to justify storing passwords in recoverable form? So that they can remind users of the old password. How do they actually send the reminder? By email. But email is not secure, you should always assume that someone is eavesdropping on your email. Far too many users reuse a password from one service on others, so sending a password in email is a huge violation of trust.

tomp 15y ago
Storing passwords in plain text (or using an encryption method) and sending password over email are two distinct issues. I think storing passwords (and not only hashes of passwords) might be a good idea if it is harder for the attacker to recover the passwords than to gain root access to the http/database server, however, I would NEVER send passwords in emails (not even newly generated passwords). A simple solution is to send a one-time login link, and have the password displayed in the browser, over a https:// https:// connection. There is still a small possibility of stealing the password (someone intercepts the email and clicks on the link before the legitimate user does), but at least the user would become aware of it (his link wouldn't work any more).
- jedbrown 15y ago
  One issue is that even if the password database is more secure than root access on the server, having the database at all means that it's possible to steal the entire thing in a small amount of time and in a way that may be difficult to detect. An attacker with root access on the server would have to keep the exploit open to continue gathering user credentials. And I still don't see what convenience having the password database offers. One-time links are definitely the right way, though I think it's better to give the user a new password dialog than to tell them a randomly generated password.
- deleted 15y ago
  [deleted]

brudgers 15y ago

[Not answering the questions] What I find interesting about the debate regarding password storage ethics is the question, "What is a website's ethical responsibility in regards to a user's password?" On the face of it, one could argue that the extent of a site's ethical responsibility ends at their IP address -- i.e. a site is only responsible for protecting one's password to the extent that it reasonably protects the user from harm resulting from someone else using their credentials on the site. For example, under this scenario, HN's responsibility would be to take reasonable steps to protect my password in accordance with the level of harm I would experience should my account be compromised. HN's "reasonable steps" are different from those of Bank of America, and emailing my password in plaintext would not shock me (even if unlikely). However, there is a tendency for people to argue that the extent of a site's ethical responsibility is to protect the user from harm elsewhere on the internet - the logic of course being that many people use the same password for HN and BOA. In some sense, this argument is premised on websites having some level responsibility for general welfare of their users (i.e. a website's responsibility towards users extends across the entire internet to some degree). A weakness of that argument is that once general welfare of the user is the standard, plaintext storage of a password may promote the user's general welfare to a greater extent than more secure measures - security is just one criteria in regards to utility. A house with few windows is usually more secure but often less healthy for its occupants. Although technical considerations are important, the issues surrounding password security methods for most sites are social: trivial passwords, password reuse, and "lost" passwords. Holding all sites to the standards which apply to sites with fiduciary responsibility such as banks or corporate IT centers is, in my opinion, somewhat asinine. Every web service does not need to be locked down, and good architecture will balance security with commodity and delight.

jtchang 15y ago

For the vast majority of sites storing passwords in the clear is a bad idea. However sometimes you need to store sensitive data. Generally this is done with hardware security modules which rotate encryption keys in a periodic basis. Access to the sensitive data is also audited. Risk can be minimized. It just comes down to if it is worth if for your business. PCI DSS is just one example of minimizing risk.

ajross 15y ago
Uh... the code in question is retrieving those passwords and emailing them over unencrypted SMTP. How is that design improved by the use of key rotation or "hardware security modules"?
- jtchang 15y ago
  By using a HSM you store the encryption key on a separate hardware device. I am already assuming that if you want to implement something like this you will encrypt the passwords. Thus the problem is knowing where to put the keys.