21–30 of 173 posts
What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.
Could you recommend a good password manager?
I abandon any sites which give me direct logins via URLs sent over plain text emails. I know, password reset keys are as bad as login keys, but usually they expire after a certain time frame. F*ck login keys.
Completely agree, Match.com does the same thing. Not so long ago a user signed up to their site using my email address (never figured out why). They were able to create an account and subscribe to the site without ever verifying the email, so for a week or so I was getting notifications sent to me without any way to unsubscribe from the email. Clicking any of the links in the email signed me in as the user and gave m…
What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.
Could you recommend a good password manager?
Earlier quoted context omitted.
Long, random password stored in plaintext: as soon as the user database is compromised, the attacker can log into your account and do whatever they want. This may result in additional exposure of information that wasn't part of the original compromise. The attacker can also impersonate you and cause other kinds of damage. Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the at…
Chances are if they have database access, they can do that already. Many/most exploits at the application layer are made to gain access to the database.
Earlier quoted context omitted.
I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway? (edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already…
The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access. Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, the…
If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own accoun
What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.
If I have enough processing power to brute-force compare them, I can eventually get the original password back, but that isn't a zero-cost effort in terms of time. As soon as you realise you have been breached, I would expect you would have initiated a lockdown of some kind, either preventing access to accounts until the owner can confirm identity, or forcing a password reset for all users.
If you store passwords in plaintext, I can copy the passwords, and impersonate users even while they continue using their accounts, unknown to them.
Earlier quoted context omitted.
Completely agree, Match.com does the same thing. Not so long ago a user signed up to their site using my email address (never figured out why). They were able to create an account and subscribe to the site without ever verifying the email, so for a week or so I was getting notifications sent to me without any way to unsubscribe from the email. Clicking any of the links in the email signed me in as the user and gave m…
This is frightening. Who is running the security teams at these large companies?
For a while I was getting emails from the Hyundai dealership that had auto-login links that would have let me do all kinds of things, including requesting a (paid) tow of the car from my house back to the dealership, scheduling (or cancelling) maintenance, ordering extras and part, and more..
Luckily through that logged-in area I was able to find the individual's phone number and we texted back and forth until he understood the problem and called his dealership to update his info.
What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.
Could you recommend a good password manager?
Earlier quoted context omitted.
The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access. Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, the…
I get that - but in a majority of cases, isn't "juicy" information going to be held in the DB anyway? Sure, you won't be able to go in through the "front door", but if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant ad…
If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own account
Often it's easier to do an injection against a SELECT, just forcing it to read an extra field, particularly now with ORMs that won't pass straight SQL through.
Earlier quoted context omitted.
Long, random password stored in plaintext: as soon as the user database is compromised, the attacker can log into your account and do whatever they want. This may result in additional exposure of information that wasn't part of the original compromise. The attacker can also impersonate you and cause other kinds of damage. Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the at…
Chances are if they have database access, they can do that already. Many/most exploits at the application layer are made to gain access to the database.
Typical case, there may be differences depending on what the attacker is after, whether the dump is publicly released, etc.