Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The company not having any access to the plaintext password would already be a huge benefit. (many people are giving random companies access credentials to their e-mail, as it stands) Although that would be hard to enforce.

They would only be able to screw users by allowing access to their own service if they were forced to provide a salt and only be able to get the hash.

  <input type=password salt=687161>
would only return the salted and hashed value.

But at html level, everything is possible and this would be hardly possible to enforce, aside from informing the user that they are typing a password into unsecure password field (hard to do, not to be fakeable, too).

It would still be hackable, by bad actors by using a salt of a service they want to get pw for, but that would at least be detectable client side.



If the salt is static, the hash becomes the password. Nobody does this.

If the hash is dynamic, the password has to be stored in plaintext. Kerberos does something like this.

Neither of these are better than the current state of the art. Read up on SRP for a public-key based system that does something like what you want.

Third party data access should go through OAuth, not by sharing passwords to services.


People share passwords, and use e-mail address to create accounts on all kinds of websites.

Anything that would prevent the website's server from getting the plaintext password would be good. Salted hash is obviously not a plaintext password and can't be stuffed around to other services.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: