Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A well-known URL for changing passwords

github.com

Post reply on HN
Print view View original

141–150 of 179 posts

Re: A well-known URL for changing passwords

#141

Post by zamalek »

gregmac wrote: post #7

This is a nice simple convenience feature, for sure [1]: > example.com provides a /.well-known/change-password resource which redirects to their change password form, wherever it happens to already be. > Password managers check for the existence of /.well-known/change-password on https://example.com . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

The one nice thing about specifying a password change API would be that password managers could change passwords automatically, but I can definitely see the elegance in not attaching it to this specific spec (it could be achieved with a meta tag or similar).

Re: A well-known URL for changing passwords

#142

Post by kibibu »

kingo55 wrote: post #118
jmeyer2k wrote: post #116

Earlier quoted context omitted.

Well it should be faster than storing a cryptographically secure hash. If hashing the data is too fast, an attacker could just brute force all of the passwords.

That's why you should always use salt with your hash. Unsalted, your password hash = Hash({{Your Password}}) The attacker can brute force it from a dictionary or stepping through characters (possibly from another breach somewhere, or a silly password like boobies123). Salted hashes are way more secure: Hash({{Your Password}} + {{Secret}}) Now the attacker has to guess an extra secret phrase, which is often really lon…

It's not enough to just use a global salt.

You need to use a random salt for each user, which is stored in the DB.

You also need to use an algorithm that takes a lot of time - SHA1 and the rest are designed to be fast, on purpose. Use bcrypt or something.

(FWIW, PHP has the best batteries-included password functions i've seen in a language. `password_hash` etc just do the right thing. Copy what they do and you'll be ok)

Re: A well-known URL for changing passwords

#143

Post by kibibu »

dancek wrote: post #126
kingo55 wrote: post #118

Earlier quoted context omitted.

That's why you should always use salt with your hash. Unsalted, your password hash = Hash({{Your Password}}) The attacker can brute force it from a dictionary or stepping through characters (possibly from another breach somewhere, or a silly password like boobies123). Salted hashes are way more secure: Hash({{Your Password}} + {{Secret}}) Now the attacker has to guess an extra secret phrase, which is often really lon…

The reason to use a salt is mostly that an attacker doesn't then have a precomputed library of hash values. Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid attacker can google for a hash search engine, input the hash and get the password in seconds. On the other hand, with salting the value to be hashed could be so…

The specific attack that per-user random salts are designed to prevent are pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using rainbow tables, so the benefits are possibly dubious.

Re: A well-known URL for changing passwords

#145

Post by caseysoftware »

hoppelhase wrote: post #123
gregmac wrote: post #7

This is a nice simple convenience feature, for sure [1]: > example.com provides a /.well-known/change-password resource which redirects to their change password form, wherever it happens to already be. > Password managers check for the existence of /.well-known/change-password on https://example.com . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

How about something like: /.well-known/delete-account /.well-known/request-user-data This would also be nice as we wouldn't need things like https://justdelete.me

That's starting to cross over into SCIM - http://www.simplecloud.info/

It's a pretty cool spec and we use it in my day job (Okta) but it's not widely implemented. If a few major providers - like Google, Microsoft, Github, Wordpress, etc - implemented it, I think it'd explode.

Re: A well-known URL for changing passwords

#147

Post by intern4tional »

hober wrote: post #117
mikeleung wrote: post #68

Earlier quoted context omitted.

looks like the change was proposed by an apple WebKit developer: https://github.com/hober which would explain why apple has implemented it...

Yup, hi.

Regardless of what happens, thank you for trying to make the web a better place.

Re: A well-known URL for changing passwords

#149

Post by jimmcslim »

caseysoftware wrote: post #145
hoppelhase wrote: post #123

Earlier quoted context omitted.

How about something like: /.well-known/delete-account /.well-known/request-user-data This would also be nice as we wouldn't need things like https://justdelete.me

That's starting to cross over into SCIM - http://www.simplecloud.info/ It's a pretty cool spec and we use it in my day job (Okta) but it's not widely implemented. If a few major providers - like Google, Microsoft, Github, Wordpress, etc - implemented it, I think it'd explode.

Seems unlikely the Google, Microsoft, Facebook and their related entities would implement this though?

Re: A well-known URL for changing passwords

#150

Post by frenchy »

kibibu wrote: post #143
dancek wrote: post #126

Earlier quoted context omitted.

The reason to use a salt is mostly that an attacker doesn't then have a precomputed library of hash values. Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid attacker can google for a hash search engine, input the hash and get the password in seconds. On the other hand, with salting the value to be hashed could be so…

The specific attack that per-user random salts are designed to prevent are pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using rainbow tables, so the benefits are possibly dubious.

Who uses MD5 for hashing password anymore?
Post reply on HN