I'd rather we hade /.well-known/delete-account
A well-known URL for changing passwords
111–120 of 179 posts
Re: A well-known URL for changing passwords
#112This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email from Teachable about an email & passwords breach. If you're a startup and you're storing plaintext passwords out of expediency, realize you're doing a massive disservice to your customers. It seems they changed this in 2015, but didn't go back and fix it for their earliest adopters. Your early adopters make you what you are! Protect their da…
There's no excuse for plaintext passwords in 2019. Even the barest of frameworks provided mechanisms to hash and salt the damn things years before 2013. Not salting/hashing at this point is more than a disservice, it's the equivalent of deliberately not washing your hands after wiping your ass, then going on to serve sandwiches.
I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems.
It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their use.
Re: A well-known URL for changing passwords
#113Earlier quoted context omitted.
Dashlane has that feature [0], though not for all sites of course. I haven't tried it out but I don't see why they couldn't have it working for say the 1000 most popular sites, which would cover at least half of my needs. [0] https://support.dashlane.com/hc/en-us/articles/202699281-How...
LastPass had a similar feature when I used it. It often broke and was overall unreliable, as all scrapers are wont to be. Worse - when it failed, you couldn't be sure at what point of the process it had done so, leaving your accounts potentially inaccessible.
That's a good point. I guess they should keep the new and the old password until you've successfully logged in with the new one.
Re: A well-known URL for changing passwords
#114Earlier quoted context omitted.
Did you read the explainer? > Currently, if the user of a password manager would like to change their password on example.com, basically all the password manager can do is load example.com in a browser tab and hope the user can figure out how to update their password themselves. > The goal of this spec is to do the simplest possible thing to improve this situation. It's an attempt to standardize the endpoint for chan…
> Did you read the explainer? I did. My confusion arose from it. Something is clear to you that is not to me :)
https://news.ycombinator.com/.well-known/change-password will just redirect to https://news.ycombinator.com/changepw. If the user isn't logged in, that page asks the user to log in.
Re: A well-known URL for changing passwords
#115Earlier quoted context omitted.
Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input. It's not expediency, it's laziness bordering on criminal stupidity/negligence.
Or maybe just ignorance?
Ignorance of facts that any reasonable exploration of best practices in the area you are working in would reveal, in a commercial venture, is a product of laziness (or hubris) bordering on (or crossing into) negligence.
Re: A well-known URL for changing passwords
#116This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email from Teachable about an email & passwords breach. If you're a startup and you're storing plaintext passwords out of expediency, realize you're doing a massive disservice to your customers. It seems they changed this in 2015, but didn't go back and fix it for their earliest adopters. Your early adopters make you what you are! Protect their da…
Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input. It's not expediency, it's laziness bordering on criminal stupidity/negligence.
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.
Re: A well-known URL for changing passwords
#117They say that iCloud Keychain on iOS 12 and Safari 12 have implemented this feature. And sure enough, https://www.icloud.com/.well-known/change-password Looking through the referenced RFC, there's a whole raft of "well known" urls that are registered https://www.iana.org/assignments/well-known-uris/well-known-... How widely adopted are these?
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.
Re: A well-known URL for changing passwords
#118Earlier quoted context omitted.
Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input. It's not expediency, it's laziness bordering on criminal stupidity/negligence.
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 long, that was fed into the hash function along with the user's password. And due to the beauty of one way hash functions both salted and unsalted hashes use the same amount of bytes in the DB... It's a no brainer.
Re: A well-known URL for changing passwords
#119Earlier quoted context omitted.
> Did you read the explainer? I did. My confusion arose from it. Something is clear to you that is not to me :)
https://news.ycombinator.com/.well-known/change-password will just redirect to https://news.ycombinator.com/changepw . If the user isn't logged in, that page asks the user to log in.
Ah I see, and from the perspective of a password manager it would know what password to fill into the password field to get the user into the site. After that, once on the change password screen said manager would also take over generating a new password, yes?
Re: A well-known URL for changing passwords
#120Earlier quoted context omitted.
There's no excuse for plaintext passwords in 2019. Even the barest of frameworks provided mechanisms to hash and salt the damn things years before 2013. Not salting/hashing at this point is more than a disservice, it's the equivalent of deliberately not washing your hands after wiping your ass, then going on to serve sandwiches.
I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems. It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their us…
At some point it should become law.
Credentials are so common and the best practices around handling them have been around for what sounds like half a century. There's no protection for the average Joe who may reuse passwords and subsequently have it exposed in plain text or through an unsalted hash.
It's logical... In fact the GDPR makes some steps to enforce better handling of personal data and announcing beaches but I don't believe it enforces strong handling of passwords.