31–40 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.
Earlier quoted context omitted.
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…
You can get a password hash from other sources besides a full DB dump. SQL injection, poorly generated tokens in URLs or cookies, etc. 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, part…
I agree that if the only information you have is a users password hash then your options beyond attempting to brute-force the hash are limited (unless the system was vulnerable to a pass-the-hash attack, of course).
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…
1. They attacked some login/api-token unrelated to bcrypt.
2. If I use bcrypt-validate for logins and only temporarily associate rotating, random login/api-tokens with an account, I should not be prone to such attacks.
Thank you very much for your help.
The domain name appears to be an anagram of Sony Pure Crime.
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.
Off the top of my head:
(1) Timing attacks against string comparison (in the hash cases, this usually also implies a guessable salt)
(2) Misconfigured servers showing exceptions/debug info to users, coupled with sensitive information in debug messages, coupled with a remotely triggerable exception
(3) Compromise only of the offsite backup site containing DB dumps but no access to the live DB
(4) Flaky drive is replaced without being physically destroyed. Dumpster diver gets drive working again briefly and gets partial/all DB contents at drive failure time.
(5) Someone else compromises the DB and posts a dump on the web.
Account read-write access opens up a lot more opportunities for fraud and abuse vs. account read-only access.
The domain name appears to be an anagram of Sony Pure Crime.
Earlier quoted context omitted.
Any attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.
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…
Many (most?) users employ the same password on many different sites. So now an attacker has email/password pairs that work not just on the site that was compromised, but also on Gmail, Facebook, Twitter, Amazon, banking sites, and so on.
Nevermind then, let's go back to berating sysadmins for implementing crypto improperly.
Earlier quoted context omitted.
Any attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.
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…