3 ms·

Given that the input password type auto filled by browsers offers no security, I propose a new standard input type called passwordhash. <input type='passwordha

by aa0 13y ago

Given that the input password type auto filled by browsers offers no security, I propose a new standard input type called passwordhash. <input type='passwordhash' hash='sha256' salt='26:$:9' editable='false'> The actual password would have to be backed in RAM if the field is set to editable. But if it isn't, upon editing it would clear the current input. Having hashes stored instead of actual passwords is of course not a total solution because someone savvy enough could use those same hashes to login to your services - but it definitely is better than plaintext - and will help stop novices from jacking your passwords. This of course requires both web dev and browser acceptance, I believe it's the future way to go With the salt option, a website could use a different salt for changing your password or for doing certain 'secure' actions. This would prevent wholesale catastrophe when an account is hijacked, effectively a salt-based level system. Thoughts?

Tinned_Tuna 13y ago
If we're up for changing the standard, why not go with something that's significantly better than pass the hash, like some form of public-key crypto? Having <input type='challenge' algo='xxx' challenge='reallylongrandomchallengetoken'> would work better than yours, I think? There's also nothing stopping the user using a "password", where that password is fed through a KDF and then used to generate the relevant private key (all done client side) -- but this is only as strong as the password used, so a really savvy user would just generate the private-key really well, and store that in a similar way to the way SSH keys are stored (i.e. passphrase). Non-savvy users can generate it a-fresh every time. But aren't we just re-implementing client-side SSL certifications?
throwaway2048 13y ago
in this scheme the hash effectively becomes your password, how is this helping anything ?
- aa0 13y ago
  Did you read my whole post? With the salt attribute, a level based system can be implemented -- effectively a different hash would be required for more critical user-actions. That is, you'd need to re-type your password in the website to perform certain actions - but it would be the same password - just a different salt.

by aa0 13y ago

Tinned_Tuna 13y ago

If we're up for changing the standard, why not go with something that's significantly better than pass the hash, like some form of public-key crypto? Having <input type='challenge' algo='xxx' challenge='reallylongrandomchallengetoken'> would work better than yours, I think? There's also nothing stopping the user using a "password", where that password is fed through a KDF and then used to generate the relevant private key (all done client side) -- but this is only as strong as the password used, so a really savvy user would just generate the private-key really well, and store that in a similar way to the way SSH keys are stored (i.e. passphrase). Non-savvy users can generate it a-fresh every time. But aren't we just re-implementing client-side SSL certifications?

throwaway2048 13y ago

in this scheme the hash effectively becomes your password, how is this helping anything ?

aa0 13y ago
Did you read my whole post? With the salt attribute, a level based system can be implemented -- effectively a different hash would be required for more critical user-actions. That is, you'd need to re-type your password in the website to perform certain actions - but it would be the same password - just a different salt.