81–90 of 170 posts
I have an argument for "username or password is incorrect" messages: it's possible that the password is correct, username exists but isn't the intended one. Then "password is incorrect" message would be lying, as the issue is actually with a username.
The solution is relatively simple. 1. Email and password for login. Don't tell the attacker which is correct. 2. Email and password for registration. On registration send confirmation email. If user is already register attacker would need access to their email. Access to email is game over. So now an attacker can't see which users are registered with your service and you've protected your customers privacy. Extra poi…
> 2. Email and password for registration. On registration send confirmation email. This opens up a different problem. It should be: 2. Email only for tentative registration. On tentative registration, send confirmation email. 3. User clicks link in confirmation email, which takes to page for setting password. (Alternatively, confirmation email includes randomly generated initial password, user is required to change i…
Ask HN: Why does Amazon allow multiple accounts with the same email address? (2014) | https://news.ycombinator.com/item?id=7075372
Interesting. Just reading this now, but it makes me wonder, what happens if you set two accounts to the same password?
The right answer isn't a blanket "sites should do this super-secret e-mail-only shuffle and not tell you anything". First, you should define your threat model: which information is considered secret and which isn't, and treat any violations as security vulnerabilities. If usernames are public by design, then don't hide them in one form, and expose in URLs elsewhere on the site. If exposing who's registered on your si…
Earlier quoted context omitted.
You mean you log onto John with password 12345 and the website says "Some other user uses this password, but not John"? Seems wrong, somehow.
More like, I log in as john with password 12345, but I forgot that I had to sign up as john87, so the password is correct and saying it isn't is misleading (even though the system doesn't know that for a fact, it is a possibility).
Earlier quoted context omitted.
You mean you log onto John with password 12345 and the website says "Some other user uses this password, but not John"? Seems wrong, somehow.
If you, as a developer, are technically able to check that the password is used by another user, you have failed pretty big at best practices.
Earlier quoted context omitted.
If the username is used as the salt when storing the hashed password in the database, it's unpossible to know if a supplied password is valid-but-for-a-different-account.
Wow, using the user as the salt is awesome. Is this considered an ok security practice?
Not quite on topic, but it would be nice if more websites would offer the option of using client side TLS certificate "login" with or without an additional prompt for a username and password. It would be next to impossible for an attacker to bypass that. For example, even if the attacker provided the correct credentials, they most likely would not have the associated client-side TLS certificate private key. Then the…
Sounds like a great solution - would browsers need to support it? Do you have any resources on implementing it?
Private keys and certs aren't as portable as passwords. Backing them up, copying them to another device, etc. lacks good UI.
Earlier quoted context omitted.
If the username is used as the salt when storing the hashed password in the database, it's unpossible to know if a supplied password is valid-but-for-a-different-account.
Wow, using the user as the salt is awesome. Is this considered an ok security practice?