Disqus Security Alert: User Info Breach
blog.disqus.com
blog.disqus.com
It is clear this is going to be a staple of internet life, so might as well be prepared.
Ideally, I'd really like something that's deterministic - ie, I can provide a seed, and then that seed plus the domain name becomes the basis for the password.
That way, it's trivial to recover passwords when sitting at a new computer. And I imagine if the seed is sufficiently long (say, a 10-word sentence that includes 2 or 3 non-dictionary words) then it'd be highly impractical to force.
Right?
Use LastPass, 1Password, or KeePass.
Use something like Keepass / KeepassXC. Yes, it's somewhat less convenient, but remember that security and convenience are always a trade-off.
It preserves the main benefit: that I no longer need to remember a separate password for each domain in order to stop sharing passwords across them.
> Now if someone steals your master password, they can generate every single password you use.
So it's just a matter of keeping the seed in the user's head and nowhere else. Right?
That doesn't seem to be any more serious a security challenge than keeping secure an encrypted datastore full of passwords.
Until you enter it on a compromised system to generate a password...
The question is: are they any more likely to gain a seed that I keep only in my head vs. a list of passwords in an encrypted datastore?
I mean, if that were my main concerns, I'd have to rethink most of the bedrock security precautions I take, like passphrases for private SSH keys, etc.
At the end of the day: I understand the risks and view them as absolutely acceptable in order to gain reasonable portability in a password manager.
In the case of your idea, once an attacker knows the seed, they have everything. Furthermore, if there's some weakness in the algorithm you use to generate passwords from the seed, then some site which has one of your deterministically-generated passwords could potentially breach the weak algorithm to reverse the process and obtain your seed, along with all your other passwords.
Lastly, with a traditional password manager, you can change the master password at any time. Would you be able to change your seed when needed, or would you need to regenerate your passwords for EVERY site, if you need change the seed because it's been compromised?
And if the domain name changes: you just keep generating for the old domain and tell the program to override.
These seem like relatively simple challenges.
There are some others:
https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...
But if you want to use one anyway, that blog post links to a bunch of them.
As for your specific qualm: I have to imagine that this can be solved by adding a numerically-determined nonce (so that I can say, "this is my 2nd password on disqus", etc) without having to fashion a new key.
edit: OK, so I have read the article. Here are my reactions to the author's four concerns:
* #1: Password schemes
> Unfortunately, sites have wildly varying and often conflicting password requirements: non-alphanumeric symbols are mandatory! Passwords must be alphanumeric only! Capital letters required! Passwords must be lower-case only! Passwords must be at least 12 characters long! Passwords must be at most 8 characters long!
> While many of these requirements seem silly and in a perfect world all sites would adopt the new NIST password guidelines, reality is messy and there is no single deterministic password generation scheme which can accommodate the password policies of all sites.
There aren't that many different schemes. Maybe a grand total of three dozen? I think that the program can simply have a user-updated registry (perhaps that's shared) of schemes, and the generator accounts for this. This seems like... maybe 150 lines of Python.
#2) Revocation and new passwords
> We could ask the user to remember the site-by-site counter and input the correct counter value to derive the correct password. But I think this is silly.
Umm, that's a strange argument. I don't think that's silly. I think it's highly practical. Currently, users remember a shitload of different details for different domains, including different usernames (this one was taken here, that one didn't meet the scheme there, etc) and often slightly different passwords.
Making them remember an integer that will rarely be larger than 3 instead of a password seems awesome. Worse case scenario, they can keep trying until they get the right one.
> You can’t store credit card numbers or bank account numbers in such a vault.
> You can’t put arbitrary cryptographic keys in such a vault.
> You can’t store randomly selected answers to security questions in such a vault.
> I consider this to be part of the basic functionality of a password manager.
I don't know what to say except that... I don't. I'm happy to have a password manager literally just manage passwords and allow me to use other tooling (like form memory in a browser) for this other stuff.
> Exposure of the master password alone exposes all of your site passwords...If you accidentally type or paste your master password into email, IM, or social media, an attacker can leverage that alone to derive all of your site-specific passwords.
Yeah, I get it - that's the same argument the others in this thread are making.
But I'm not going to accidentally type along seed, like a 10-word sentence with punctuation, into any of those places. This seems like a completely absurd argument to me.
Edit: and this point is actually made in the article the GP linked.
> Making them remember an integer that will rarely be larger than 3 instead of a password seems awesome.
Ok, so, we have the "master seed" that has to be remembered. We also now have to remember X from [1..36] of schemes, and a Y version integer.
There's two ways to "remember" these triplets. In your head. I which case you have to remember, for all 50 [1] different logins to all the sites you have, a triplet of <master,scheme,version>. Master will be easy, as it will be typed enough times to be easily remembered. But remembering that site A, that has not been visited for 4 months, used <master,14,2> while site B, that as not been visited for 6 months, used <master,27,3> and so on for 50+ logins will be untenable.
Or your 'deterministic' generator really has to store the "scheme" and "version" parts of the triplet somewhere in a local file/db, associated with each site, to allow it to work. At which point, you are 80% of the way to a proper password manager that would allow each password to simply be a proper randomly generated string of characters, tailored as need be, for each site.
> Worse case scenario, they can keep trying until they get the right one.
Unless, because of breeches or general password rotation they are now up to "version 12", but the site only allows three tries until lockout. Now you have to start trying "within 3 steps" of 12 or else you are guaranteed to be locked out.
[1] In the manager I use (Password Gorilla, https://github.com/zdia/gorilla, which is one of the many Password Safe compatible managers) I've got 371 stored entries, of which 285 are actual passwords for various sites that wanted a registration of some form or another along the way. That is something you learn quickly when you start using a password manager. The sheer number of websites that want you to 'register' in some way or another is actually huge. This is after about 13 or so years of using a password manager.
That counter can be exposed publicly as well as likely a regularization mapping to coalesce variants in the domain name to a single value, having those are pretty worthless without the secret. So I think that just need to be kept secret and then everything else can be kept in dropbox or wherever.
Edit: I missed it on first glance but I see that this is referenced in the link you posted, so nevermind then.
You manage security: KeePass
I use KeePass with a keyfile and password. The DB is stored and sync'd across devices in DropBox, I have my DB and key regularly backed up on a USB drive. The key is also present on some machines that I cannot easily add the USB to (eg. phone). It's the only password I need to remember -- I have literally hundreds (400+) of accounts. I do not regret it at all -- but it was a huge pain to migrate everything to it.
I also store my Google authenticator initial QR codes on it, in PNG format.
However, storing 2fa codes alongside your password is still more secure than not. If the service password is compromised without the 2fa seed (main threats: MITM, phishing), the one-time password prevents the account from being immediately compromised.
1. You can't change your master password without changing every other password (upon refresh - looks like others mentioned that already)
2. You can't modify the output of your deterministic password algorithm to adhere to sites with weird password requirements
I agree with everything Tony Arcieri wrote about deterministic password managers here: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw....
Before you consider a deterministic password manager, just use "pass".
Hope this helps.
[1] http://orgmode.org/worg/org-tutorials/encrypting-files.html
Everyone seems to treat password managers as an arcane mysterious tool and acts temporarily amnesiac to the fact that every browser that anyone has used asks if you want to save your password. Both Firefox and Chrome let you sync your passwords between multiple computers, and I believe both do it in an end-to-end encrypted way.
in chrome, the end-to-end part is opt-in. https://support.google.com/chrome/answer/1181035?hl=en
Sorry, But Your Browser Password Manager Probably Isn't Enough https://www.wired.com/2016/08/browser-password-manager-proba...
Why you shouldn't use your browser to store online passwords https://scotthelme.co.uk/storing-passwords-in-browser/
It has browser extensions (Chrome, FF, & Safari), local storage (with many cloud-sync options), and apps for Mac, Windows, Linux, iOS, Android, etc.
The desktop versions are free and the mobile version is about $10/platform (lifetime license).
I have no connection with the company, just a very pleased user.
Warning though, I stopped using it because seed + domain doesn't guarantee that the password will fit the sites password requirements.
If you want to sync across multiple computers, you can throw it in whatever file sharing service (Dropbox, Google Drive, etc) you use. Personally, I prefer Spideroak[2] due to their strong privacy policy.
First of all: Don't be afraid of using one. It's not just more secure, it's super convenient. Never again will you ask yourself: Did I make an account for this website/service? What email did I use? Never again will you have to remember a password. Using a password manager is a quality of life improvement.
KeepassXC is what I recommend to people at this point. It's free and you own your data (your passwords). They live wherever you want them to live. There are plenty of online services that are supposedly more convenient but I have to say I trust them less -- YMMV (1Password is the best I'm aware of).
If you do use keepassxc, you get the added benefit of being able to store 2FA settings in it as well (if you store them in the same database as your passwords, be aware that you lose the security benefit of a second factor, however it is still more secure than not having 2FA enabled due to the One-time password component).
Put every account you ever made and ever make into keepass. Enable 2fa wherever you don't have it enabled. Add login URLs and notes. Generate your passwords from keepass itself; the password generator is really powerful and lets you very easily deal with site-specific shitty password limitations. I'm telling you this because, seriously, it's incredibly convenient to have this stuff as long as you're rigorous about maintaining it.
Oh, also, keepass has the full history of all your passwords. Need to look up an old password? Go into details and look at "History". You can also attach files to items (items don't have to be accounts at all, you can use keepassxc as a simple encrypted storage db).
Mobile support: Keepass2Android. Best android client, with google drive support. iOS I have no idea, suggestions welcome.
IMPORTANT: BE STUPIDLY PARANOID AND RIGOROUSLY CAREFUL ABOUT YOUR MASTER PASSWORD. That thing, together with your keepass database, unlocks all your accounts ever. Use a really long passphrase that you will never have to write down (if you do decide to write it down because you don't trust yourself, store it in a safety deposit box, don't put it in a bloody drawer). Make sure the device you unlock the database on is malware-free.
PS: Wondering what's up with Keepass vs. KeepassX vs. KeepassXC? Keepass is the original app, written in .NET but with poor multi-platform support. KeepassX is a rewrite in Qt and is a fantastic password manager, but has gone unmaintained recently. The open source community picked up the slack in the KeepassXC fork (after continuing countless attempts to upstream the patches) and has implemented lots of powerful features. I've switched to it and at this point I strongly believe it's the better client.
My solution is to develop an algorithm for all my passwords that is pretty quick and simple to memorize but allows me to "generate" a unique password for each service that I use.
Although I seriously doubt anyone could figure out my algorithm by learning one of my passwords, I'll admit that if they were to gather 3 or more then they'll probably be able to figure out my system. But since I never write down or record any passwords whatsoever (all I need to remember is my algorithm), someone would have to steal my credentials from multilple sources and also be able to know which credentials from one service match a user from another, etc.
2. Search for any combinations of john, garrison, and any other names I can determine by looking up your comment / post history here
3. Check the list of results to see which appear to be reasonably complex and of similar construction to determine which are likely yours. People with "good" passwords are very much in the minority, so this should be pretty straight-forward and mostly automatable.
4. Manually try to determine your scheme, which according to you is probably doable with this information.
---
Not saying it'd get you for sure, but if your replacement of a password manager is hamstrung by knowledge of at most three of your previously used passwords, you're probably doing yourself a disservice.
Thanks to social engineering, email address reuse is the new password reuse.
I read your comment just after you posted it and thought, "oh I haven't gotten an email yet, I must be safe". . 50 minutes later it came through :-p
Still, the state of the industry is pretty shocking. We are doing more and more stuff (super-encryption at rest, constant password rotation, password managers etc) and still breaches happen with regularity. It feels a bit like when Office started having a system to recover documents after a crash - yeah, great, but why is the crash happening so often that we need it in the first place?
Where by "unlikely" we mean "with almost complete certainty".
In many ways the old world of dispersed forums were much better and are still better content wise than anything Reddit can throw up.
You can share photos and remain connected to family and friends without needing anything like facebook. This kind of centralization only favours self promoters and exhibitionists and shifts tremendous personal data patterns to entities who have no business having or analyzing this data. No one should have access to this kind of data as the consequences can only be negative.
Data Minimization.
It seems they had a old copy of the database, likely a backup, just sitting around somewhere. The question is why did this old copy, from 4 years ago, still exist. Why was it not deleted under a standard data retention policy.
Companies not only need to spend time on how they will secure data, they need to spend time on how they will age out and delete old data.
I don't know what the effects are of them (including this one), but my gut tells me they'll only increase over time; perhaps the severity of them as well.
It's honestly making me re-consider my use of the internet, technology, and electronics.
What's the future hold with regard to security, breaches, and keeping our data and information safe?
I wonder if there will be any information private by then.
This should be no surprise if you're a developer. "Lean/'agile' companies" have tried to cut cost so agressively that we don't have QA teams, tickets have to go as fast as possible, etc.
Businesses won't care about this until it hurts their bottom line. Even then they'll deny that it's possible.
It is the rate at which they are being published that is alarming to you, the rate at which they are actually happening is much higher still.
Current gpus can hash tens of millions of passwords per second with SHA-1.
[A GTX 1080 can do ~8.5 billion hashes/second][1].
An 8-character, truly random password with mixed case, numbers, and symbols has (26 * 2+10+32)^8 possible combinations.
That means an attacker with a single GTX 1080 could crack such a password ((26 * 2+10+32)^8/2) / (8538.1 * 10^6)) seconds ([approximately 4 days][2]) on average. And most user's passwords are most certainly not truly random (i.e. they're significantly weaker than that).
[1]: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
[2]: https://www.wolframalpha.com/input/?i=((26*2%2B10%2B32)%5E8%...
I would assume that there is always a 1 to 1 relationship of user account details to passwords, or that the passwords are stored within the user table in the DB, so at best, X=Y at all times?
I can understand if it is a current breach and the DBAs managed to stop a transfer of data mid query, but in a 4 year old database (in this case) where only hackers only have partial data for passwords, but full data for user accounts?
And many blog posts explains what how he does it: https://www.troyhunt.com/
Pretty sure this is the one he mentioned in his video today as having been given to him by someone else.
Based on the little information published, it sounds like that's what has happened in this case as well.
The same guy has also found tons of wide open MongoDB instances and such.
The guy you're referring to, Troy Hunt (HIBP) , writes about these cases but, AIUI, doesn't typically find them on his own. He's usually notified by the actual "researcher" -- this Chris guy in a lot of recent cases -- and they share the info with him.
Did this recently and found 1000’s of public buckets.
That said, I'm sort of happy 1password switched to subscription billing - hopefully this lets them pay top dollar for the best security experts.
(Having a separate domain is not really necessary, but I registered it through nearlyfreespeech.net and use their WHOIS privacy service; at least J. Random can't easily figure out my identity based on the email address alone).
Nonetheless, you have a point!
FYI, the requirements for a password hash function is significantly different than for a cryptographic hash function. the vulnerabilities you're talking about doesn't affect any of those properties. password hashes only need to have preimage resistance, and (more importantly) be slow as to limit offline attacks.
SHA1 was useless for passwords long before then.
SHA1 is a fast hash. It's designed to be tractable to calculate lots of SHA1 in a small time. This is independent of whether it has collisions and is considered broken. It was fast from day 1. Fast hashes are not suitable for protecting passwords. They were never suitable for protecting passwords.
Honestly, I feel like when we wrote that dumb bcrypt post in 2007, it was already a bit negligent to be using unstretched general purpose hashes for password storage. The BSD's used better hashes in the 1990s.
Today, in 2017, bcrypt remains a sound recommendation. You can do better, but for password databases on websites, not materially better.
Salted SHA-1 hashes (salted SHA-anything hashes) were malpractice in 2012.
I agree with you, but it was very strange to discover that password storage is basically ignored in pentests. Especially after years of you drumming it up as a big deal.
I wish they did. It would be nice if they were forced to care. But it wouldn't block them from being declared secure by a pentest. Low-severity findings are findings, yes, but they don't have the same pull as medium or high severity vulns.
All of this is true for storing passwords in plaintext, too. If some company leaked plaintext passwords, people would be outraged. Yet pentests would still give that company a pass, because plaintext password storage is sev:low.
Do you mean using scrypt? What do you mean by materially better?
"better" means "cannot be calculated much faster on GPU or even FPGA because it requires a lot of RAM".
"materially better" probably means "less than a million of hashes per second on eight Nvidia GTX 1080 running hashcat"[2], so Django and scrypt are both good (adjust work factor as needed, of course).
1 - https://en.wikipedia.org/wiki/Argon2
2 - https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
Scrypt is better than bcrypt, but mostly not in ways that make much of a difference in 2017.
PBKDF2 comes close to being materially worse than bcrypt and scrypt, because it's especially straightforward on modern hardware, but even PBKDF2 is fine.
For the most part, as long as you're using anything with a KDF-like design for your password hash, a compromise of your password database is going to reveal the very terrible passwords and only those passwords; the rest will be too costly to crack.
Right now given the choice I'd use scrypt and go slightly out of my way to get it (if there was a good 3rd party library for it and bcrypt was in the standard library and I was like a "yarn add" away from having it, I'd take that step), but I would not convert a bcrypt site to scrypt.
PS My measurements show that pure JavaScript implementation of scrypt is better than fast native PBKDF2 provided by WebCrypto API or Node.js at the same running time.
PPS But yeah, if you can't use bcrypt/scrypt/Argon2, but can use PBKDF2 with high number of rounds, sure, do it.
I'm pretty sure this is still the only option on Google App Engine. You can't upload C code, so bcrypt isn't an option.
1 - https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
2 - (pow(26+26+10, 8) / 2*pow(10, 11)) / 60
A dictionary-based attack that tries variants and inserts digits and spends one second per hash will catch the less common passwords.
And in 2012 the current breaks from this year were not yet known. Some considered sha1 to be in its twilight, but it was not 'broken' yet at that time.
But without knowledge of what was coming for sha1 in five years, back in 2012 it would have been a much better choice than either MD5 or plaintext storage.
However, even today, with the knowledge we now have regarding sha1, if ones choices are limited (for some strange reason) to only sha1 or MD5, sha1 is still a better choice than MD5. Yes, sha1 is weak, and it should clearly not be used for any new designs, but sha1 is still stronger than MD5.
Also note, the 2012 date was when they last used sha1, not when they started using it. That fact is somewhat critical to keep in mind. They last used sha1 in 2012. What got leaked were some leftover hashed passwords that never got updated to bcrypt that were still hanging around in their database (probably because those accounts have never logged in for the last five years and been forced through a password change).
The article announcing the breach contains the term "SHA1" in exactly two places: "passwords (hashed using SHA1 with a salt;" and "password hashing algorithm from SHA1 to bcrypt".
Absent evidence to the contrary (of which the article provides no such evidence), I am reading "hashed using SHA1 with a salt" to mean they used this construction:
Hp = H(S||P) or
Hp = H(P||S)
where:
S is a salt (derivation method unstated)
P is the plaintext password
|| is byte concatenation
H( ) is a hash function (sha1 in this specific case)
applied only once to the input bytes
Hp is the "hashed salted password"
The "password hashes" PBKDF2, bcrypt, scrypt, and Argon2 are all designed, the same way a KDF is designed, to mitigate this attack. All of them have a "work factor" that requires you to iterate the underlying hashing primitive (which might very well be SHA2) many times before arriving at the answer.
SHA1 and SHA2 aren't password hashes. That's what people here keep trying to explain. None of the well-understood flaws in MD5 and SHA1 are really relevant to the password hash setting. They're a disaster for cryptographic signature constructions, but they do not matter at all for passwords.
that's BS to think sha1 was the best hash you could pick in 2012
I said it (sha1) was significantly better than MD5 or plaintext. That neither says nor implies that sha1 is best, just that it was better than other options that some might have chosen in 2012.
The problem is that MD5, SHA1, SHA2, and SHA3 are not password hashes. The password hash constructions in common use are PBKDF2, bcrypt, scrypt, and Argon2. Some of them use SHA2 as a primitive, some of them don't, but none of them work by simply concatenating a salt with a password and hashing.
Password hashes only help protect against brute force searches by increasing the cost to attack linearly with the cost to verify. But that isn't a great tradeoff and isn't future-proof.
As long as you're using a password entry field designed for manual entry, you can't credibly counter that with "people should use password managers and autogenerated long line-noise passwords". Because you can't base your security upon all your users taking the initiative and doing the power-user non-default thing.