Hacker News Reader

Comment by samuel | Hacker News Reader

With a hardware device as a smart card.

Everyone here implies that passwords are stored in just another table of the database. There are other more sensible scenarios. For exmaple: authentication servers which talk to the front end using CHAP, well behind internal firewalls and with dedicated hardware which holds the private keys and encrypts/decrypts the data.

This has been discussed before. The ability to recover passwords has bussiness value, so at the end its a tradeoff between risk and money.

View on HN

if your application can access the password, there is a very high chance so can somebody that has application level access to your machine can just do whatever your application does, you cannot hand wave that away with "smart cards", "encryption" and "firewalls".

Having a stored password in any format except for one way hashing is a massive and _unnecessary_ liability.

Before you take the time to reply with another convoluted shell game of keep the password away from the hacker, consider the actual necessity and value of a recoverable password. Does it really outweigh the massive security problems?

Anyone that has application level access to your servers can still get your password very easily, for example every time you log in. Why is having a means to decrypt the password so much worse?

You misunderstand the point of password hashing, it is not about preventing people from breaking into the machine containing the hashes, it is about limiting the damage they can do with millions of passwords as a result of doing so. Most people do not bother to change their password from service to service, login to login. So instead of a breech on one system, you potentially have a breech on thousands.

Think you misunderstood GP's point: With enough access you can simply wait for the users to log in and steal their password when they do.

Not if you are doing your login correctly. You shouldn't need to send passwords to a server to login, just hashes of passwords. That's the point. If your server ever needs to see a real password after the account is created or the password is updated, you have introduced a new vector of attack.

Done correctly, login is an exchange of hashes, not encrypted passwords.

How so?

A simple way to do this would be to send a unique, random salt S for every login, and the user would reply with e.g. sha1(password + S). However, to be able to check that the answer is correct, you would need to know the user's password, in plain text, which brings you back to square one.

To securely do this, you would need commutative hashing functions, i.e. hashing functions f(x) and g(x) such that f(g(x)) = g(f(x)). Actually, to be completely safe, you would need to be able to generate a whole (preferably infinite) family of commutative hash functions g(x), a random one for each login. I have no idea if such functions exist, more importantly, if they are known, it's an interesting idea actually.

The web is not exactly the state-of-the-art in network security and encryption. What GP is suggesting is common in other scenarios.

Since you can't trust the server in this scenario, you can't implement in in (normal) javascript.

In most cases, anyone that has application level access can already do the things an ordinary user needs authentication for. The password is irrelevant, unless you want to find it out to access another system you don't already have permissions for.

You say it's _unnecessary_ and "there's high chance of someone accessing the password". Under that premises, obviously, it's foolish not to use one-way hashing. Mine is that may provide value and there are sensible ways of mitigating the risk, miles away from accessing the data directly from your application, by using software and hardware designed and implemented by security professionals. That's all.

The problem is, the application fundamentally HAS to be able to access the password, either through direct comparison to authenticate, or some mechanism to mail out the password. This fundamentally cannot be separated, that's why hashing is always better, and why the risks are nearly impossible to meaningfully mitigate.

How does that statement hold true? I can easily think of an application that just uses a simple service on a separate box behind a firewall that only accepts an email and then sends the password. Authentication works via CHAP or any other auth protocol. The application itself never has access to the plaintext password. Granted, an attacker may gain access to the app-server and then proceed to crack the authentication server, but he could also just rig the application to pass on any password it receives. Just about as good as cracking the auth server and far easier to do. (Added bonus: works for hashed passwords just as well). Granted, this may seem tons of work for a simple solution, but from there on, it's a business decision.

> Everyone here implies that passwords are stored in just another table of the database.

Because if you send back passwords in plaintext, they usually are...

Reply on news.ycombinator.com