5 ms·
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
by nilved 11y ago
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.
- valarauca1 11y agoCould you recommend a good password manager?
- hattenn 11y agoTry LastPass.
- nilved 11y agoSelf-hosted: http://www.passwordstore.org http://www.passwordstore.org http://keepass.com http://keepass.com http://keepassx.org http://keepassx.org Paid: http://lastpass.com http://lastpass.com http://1password.com http://1password.com
- mr_sturd 11y agoI'll second nilved's suggestion of KeePass. The database is encrypted and stored on the local machine. I currently use Syncthing to share it between my devices.
- mikejarema 11y agoLikewise, I'm very happy with this exact setup after coming from a mix of memorized password and site-dependent password-generation schemes. I'm on Mac and found KeePassX to be a better solution than the original KeePass, it's much lighter weight. My only hope is that KeePassX gets browser integration at some point via keepasshttp - https://www.keepassx.org/dev/issues/91 https://www.keepassx.org/dev/issues/91
- mr_sturd 11y agoAh KeePassHTTP would be lovely on Android, too, but I'll live with temporarily stashing the passwords in my clipboard for the time being.
- deleted 11y ago[deleted]
- yrro 11y agoI use https://github.com/jamessan/vim-gnupg https://github.com/jamessan/vim-gnupg
- brusch64 11y agoI like KeePass and use it daily.
- smacktoward 11y agoI use KeePass as well, and have had no problems using SpiderOak to securely sync my password database across devices. (Though I've heard noises recently about KeePass's .kdbx file format having some known vulnerabilities. Anyone else heard this, or have more details?)
- jszymborski 11y agoFrom what I've heard, people are generally just concerned that the database is not authenticated whatsoever, and so a malicious actor can modify your database (particularly if it's hosted on Dropbox/etc...). This doesn't seem like a particularly scary vulnerability, but one scenario that was brought up (though I'm not 100% convinced), is that a malicious actor can corrupt the password for one website, leading you to change the password. I dunno, don't see it as a huge vulnerability, but I do agree there is little reason for such a database not to be authenticated.
- zeveb 11y agoI like Password Safe (https://www.schneier.com/passsafe.html https://www.schneier.com/passsafe.html), although I do wish that it used AES-256, SHA-384 &c.
- sillysaurus3 11y agoAny attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.
- JosephRedfern 11y agoI 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 have access to the data that knowing the password behind the hash would provide).
- nerdy 11y agoThey may not necessarily have compromised the entire system. Consider for example, SQL injection. Alternatively, some kind of DB dump mistakenly exposed in the webroot. Neither should happen but they're real-world examples. Sometimes misconfiguration leaves you in a weird state.
- sillysaurus3 11y agoThe 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, they won't be able to use any info within it to log in as anyone else unless they use brute force to reverse a hash. EDIT: It's true that the attacker might have a copy of all the user's data. But unless they know someone's plaintext password, they can't log in as them. The attacker might have a copy of your tweets, but they won't be able to log in as you and send a new one. There are only a few ways an attacker can snag a database. Most of the attacks let an attacker download it, but not modify it. For example, directory traversal lets you download ../../../../etc/passwd along with ../../path/to/database_backup. Even if an attacker has shell access, it's unlikely they'd be able to use the service or change a user's password by manipulating the database directly. They might not be able to modify database for a number of reasons: the database might require credentials the attacker didn't get, or the attacker might only have access to a server containing database dumps rather than the database itself, or the attacker might be logging in as a user which has read-only access to the database file.
- kijin 11y agoLong, 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 attacker gets the user database and nothing else.
- nilved 11y agoChances 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.
- pyre 11y agoSQL Injection is an application layer exploit that gains the attacker access to the database, but does not involve any sort of privilege escalation. Consider this: an attack gain access to your bank's user credentials database. Do you want them to have access to your unencrypted password? Is it really so "harmless"?
- kijin 11y agoWorst case, there will be no difference between plaintext and hashed passwords. Typical case, there may be differences depending on what the attacker is after, whether the dump is publicly released, etc.
- KMag 11y agoThere are a significant number of ways paswords/password hashes stored in a DB might be revealed that wouldn't result in write access to the DB. 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. A big part of good security is taking steps to keep small errors from being leveraged into big problems. (Though, I'm not saying that read-only access is only a little problem.) Account read-write access opens up a lot more opportunities for fraud and abuse vs. account read-only access.
- deleted 11y ago[deleted]
- stephenr 11y agoIf I breach your environment and get access to bcrypt hashes, they are useless to me as-is. 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.
- steckerbrett 11y agoIf you have the computing power? If you're compromising peoples boxes you likely also have a botnet, which has practically limitless potential.
- Piskvorrr 11y agoNo. Given a large enough work factor, there literally aren't enough resources in the entire universe to brute-force even a single hash. "Hard to imagine" and "limitless" are very different animals. Edit: moreover, the GP has already mentioned that "[brute force] isn't a zero-cost effort in terms of time," even if you have access to humongous amounts of processing power. The point of encryption isn't to protect data forever; just long enough for them to become uninteresting.
- steckerbrett 11y agoLimitless in the sense of applicability to tasks.
- wtbob 11y ago> Given a large enough work factor, there literally aren't enough resources in the entire universe to brute-force even a single hash. Or, given a strong-enough original password. I postulate that, until the moment I posted it, '3BgZhZcGPcHswmfic79jgjsfqyMKW1Rh1rkFjagJC090V2tljd9Zy2vpYJw944HG' would never have been brute-forced, even with an extremely low work factor (in fact, it wouldn't have been brute-forced even without bcrypt, scrypt or PBKDF2: even were it just stored as a simple SHA2-512(pw) (i.e., baafbe64d25f27d4b7b2965f9abf43cf25acd8fc6021798a90253f33b3071e9 fd145eaccd555290913c8679fd4acf949f05243ac1089548abbab0e0ed77e63 31), no computer on earth, nor all the computers which ever have been or ever will be, would have brute-forced it (unless there's something we don't know about SHA2, or about computing). Lesson? Always use high-quality random passwords. For a 128-bit security level, with upper- and lower-case letters & digits (62 characters, which means each character yields (log 62 2) = 5.9542 bits of entropy), you want a 22-character truly random password. 'xNl5gkbgXntyxi3oNO1dML' is a perfectly fine password (save for the fact that it's now public). According to the NSA [1], 256-bit keys should be used to protect data up to TOP SECRET; that works out to 43 characters. Hence, 'TIdmzj1COc9ECwcilyQYVfLl5Dt8ti3UUlDVULrUrfx' is as secure an example password as could be. (Yes, I'm assuming here that your password-generation algorithm is truly random. If not, do not pass Go; do not collect $200…) [1] https://www.nsa.gov/ia/programs/suiteb_cryptography/ https://www.nsa.gov/ia/programs/suiteb_cryptography/
- throwaway2048 11y agothat is a ridiculous assumption that only leads to really silly "if the 8 planets are aligned just so" kind of justifications that make people feel fine with awful security practices.
- lostcolony 11y agoLet's also assume that any given server will never be hacked. It's more realistic.
- ddlatham 11y agoWhile uncommon, it's not ridiculous. A site could, for example, decide to generate a user's password rather than allow them to provide their own, thus guaranteeing it be long, random, and unique. However, it's still not a good idea to store such passwords in plaintext.
- lostcolony 11y agoGood luck keeping users by forcing a long, random, unique password on every one that signs up.
- patio11 11y agoWhat's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This assumption is known to be false. We should not design systems around this assumption. If we do, popping a random startup will give up Gmail accounts, by the thousands to tens of thousands, and since we've settled on email accounts as The One Ring To Your Identity that imperils their brokerages, domain registrars, employers, World of Warcraft characters, physical safety, privacy, cat photos, etc.