Security Update
stackoverflow.blog
stackoverflow.blog
As far as I can see, the primary sensitive user data they have is e-mail addresses, but (unlike, say, Reddit) most StackExchange forums don't deal with personally embarrassing material and many of if not most StackExchange users post with handles easily associated to their real names.
Of course, that is all speculative until the extent of the breach is released. From the press release, they seem to imply that the only affected areas were public facing.
Listings you've applied to could be potentially private. But if you use an alias (and only reveal your real name after the company agrees to interview you), then it's not a problem either!
Do you do that? Do you know anyone that does? If so, how do people react to it?
My google profile is also an alias. My facebook profile is also an alias. My twitter, same. And if i had a linked-in profile, it would be an alias too. Some of those alias may be the same, but some i deliberately make different, so that i can choose whether others can associate different aliases together as the same person.
Why anyone puts their real name online is beyond me. When i tell my real life friends, they are shocked, and also ask whether it's inconvenient. Yes, i would answer - it is inconvenient, but it is more control. It gives you the option to prevent others from being able to track all my activities online across different services (at least, not easily).
An alias is not privacy :]
No, absolutely not.
If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them.
Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify the work of a time consuming attack on the hashes.
Jeff wrote this in 2007:
> Do not invent your own "clever" password storage scheme
> Never store passwords as plaintext.
> Add a long, unique random salt to each password you store.
> Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier than he actually is. But he's right. MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 or Bcrypt would be a better choice.
https://blog.codinghorror.com/youre-probably-storing-passwor...
Another topic on passwords: https://blog.codinghorror.com/the-dirty-truth-about-web-pass...
As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene number of SHA-2 hashes per second. Bcrypt is is intentionally much slower and harder to use a GPU to brute force. The two algorithms are almost totally unrelated and it's concerning they were mentioned together.
[1] - https://tools.ietf.org/html/rfc2898#section-5.2 [2] - https://en.wikipedia.org/wiki/Bcrypt
It really depends on what the person means. Yes, single sha-2 hash is pretty useless. But that's often not what's really happening. For example libcrypt is used in many cases with the default $6$ format which uses thousands of rounds of sha512. That's still "password hashed with sha-2".
You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
Of course, that only works for active users - it won't upgrade anyone that never logs in. Depending on just how weak the old hash is, you may want to eventually cut off any lingering un-upgraded accounts: just forget their old hash, requiring them to go through your password reset process should they ever come back. If you've left it long enough, those accounts will probably never be used again anyway, so that should be NBD.
For the purpose of hashing passwords, there's no significant difference between MD5 and SHA-2. Both are awful choices.
Edit: Actually, SHA-2 may be worse because CPUs have hardware acceleration and thus the attacker may be able to crack it somewhat faster than MD5.
If my password is "password" you can probably guess that almost instantly no matter what scheme is used. If my password is 32 characters of random base64 output then it wouldn't matter if the scheme is MD5($password) you won't guess it.
Schemes like PBKDF2 and bcrypt trade something useful in the middle, if your password is mediocre they make it too hard to bother guessing. But you'd need to define how mediocre it is to get a meaningful estimate.
In a good case, it takes 50ms per hash on a modern system, so that's 20 attempts per second (instead of 20 billion per second for a plain md5 or so). I don't really expect a popular site to do much more than that, so that's the best case. From experience, most sites will be more around the 20 billion mark than the 20 mark, but I expect stackoverflow to be on the good end.
The current state of the art is Argon2, with scrypt second and bcrypt/pbkdf2 tied for third. The first two have memory hardness, and the first one is the standard chosen in the password hashing algorithm competition. The third is still acceptable because most developers still go for a salted single hash like sha256. Somehow they got the salting method, but I'd rather they break all identical passwords at the same time (they weren't that strong anyway if they're shared between more than one person) than that they crack only a tiny percentage because of the cost. Slowness helps more than salting, yet as a pentester I see more of the latter than the former. So I'd rather recommend something available for their platform as a good third choice than them going "meh, effort" and not implementing the recommendation.
Details for the interested implementer: there's a lot of bad software floating around out there, be careful and do your due diligence.
Use the argon2id function. If the language binding does not expose the argon2id function, but only argon2i and argon2d, then it's outdated, avoid. If the library has not been updated past 2016 (argon2 v1.3), it's vulnerable, avoid. (Some language bindings ship with an embedded library.)
Language bindings to the argon2 library do not document how to pick good parameters because language binding authors do not understand nor care about security, the suggestions in the synopses are laughably undervalued. Compare with the expert recommendations in https://password-hashing.net/argon2-specs.pdf chap. 6.4, 8, 9 and https://tools.ietf.org/html/draft-irtf-cfrg-argon2#section-4 .
Algorithm for picking the correct values on the target server hardware:
const PASSPHRASE := 6 random words from dictionary
const SALT := 16 bytes from urandom
const DURATION := 0.5 ### or greater; this is the maximum amount
### you are willing for your user to wait
mut T_COST := 1
mut M_FACTOR := concat(4096, 'M')
const PARALLELISM := `nproc`
const TAG_SIZE := 16 ### bytes, or 128 bits
while {
const TIMER := benchtime argon2id(
PASSPHRASE, SALT, T_COST, M_FACTOR,
PARALLELISM, TAG_SIZE
)
if TIMER > DURATION {
if 1 === T_COST {
reduce M_FACTOR ### e.g. divide by a constant
jump to top of while
} else {
jump out of while
}
}
print T_COST, concat(M_FACTOR, 'M'), TIMER
T_COST := T_COST + 1
}Hashed passwords are cracked so easily it is a minor obstacle at this point. It is a question of when not if a hash table is fully cracked.
Modern cryptographic hash functions that are tailored for password hashing (such as scrypt or Argon2) are much harder to brute-force and have tunable knobs to allow you to increase the memory or CPU hardness. Obviously you cannot be safe forever but if you have a database dump of Argon2id-hashed passphrases with very strong parameters you aren't going to break it any time soon.
Also you do not need the hash table of a hardened system to get useful passwords. You need a reused password from a weak one.
Not related to stackoverflow though.
>You need a reused password from a weak one.
If the weak password is already public, what is gained by finding out that it's a weak password in a strong DB? You've just described a dictionary attack.
I can see from the downvotes the very idea that it is in regular use as triggering for some folks—-but md5 and other weak hashing algos are not just in obscure anime forums but in systems everywhere.
“They don’t like to think it be like it is, but it do.”
And it isn’t about md5 hash rate it’s about the ease of cracking in general due to low cost of compute.
If the SO password hash has leaked even in bcrypt its going to be attacked and many strong passwords will be broken. If they are reused elsewhere, important email addresses will be attempted elsewhere.
Don’t reuse passwords.
Nobody here disagrees with this premise. I just disagree that "low cost of compute" changes the fact that functions like Argon2 can be tuned to become more expensive to crack based on changes in computation cost. If you're worried about someone spinning up something on AWS to crack hashes, bump up the memory and CPU hardness and now they'll have to spend much more money to crack your passwords. In addition, the design of most modern password hashing functions is such that you get poor parallelism on GPUs.
edit: here is the demo video: https://www.youtube.com/watch?v=KnD4f8N1_OE
More meaningful would be the speedup compared to a single CPU core, which is what the developers (should) benchmark against. They should make it as slow as possible, so if their system can do bcrypt with a cost of 15 in 0.1 seconds, they should set either that or cost 16. (Much more than 0.2s might be annoying to users or be a DOS vector.)
You can't really call that a "right" setting when it takes at least as long to log in...
...? At 48 trillion hashes / second, you could get the entire hash space in as little as 224 quadrillion years.
Of course, if you had any collisions, it would take longer. A lot longer.
This suggests that strong passwords are still just as strong under md5 as under a more modern hash. No? Use of md5 is a problem because people use passwords that are easy to guess, not because you can enumerate the hash space. The one-way-ness is as secure as ever.
Given random salt (random placed or mixed) or HMAC, you have to use the more complex preimage attack at 123 bits.
This is crackable with a medium sized botnet or a supercomputer.
48 THash is an underestimate. Specialized hardware easily surpasses this, even FPGA does.
SHA1 salted is a tougher customer with 60-64 bit collision resistance meaning you probably cannot crack it with your calculator. However, it is still prone to length extension meaning predictable salting has this much strength.
What problem are you trying to solve? As I understand it, we're discussing enumerating the hash space, such that:
1. You are given a hashed value, such as 2b0f4e60b80da7ef1e84573d764f1bf4 .
2. The value is someone's hashed password. You need to find any string which hashes to this particular fixed value, but you don't know of any such string to start with.
You can do this by brute force, but it will take you a long, long time.
The problem is NOT:
1. You have a string which hashes to a particular value.
2. You want other strings which hash to the same value.
And it also isn't:
1. You have a string which, with an unknown prefix, hashes to a particular known value.
2. You want to identify hashes which represent the same string with other prefixes applied.
I don't see where salting is relevant to the question. It's a defense against the phenomenon that cracking one user's password automatically also cracks everyone else who uses the same password (since, without salting, they all have the same hash), but it isn't a defense against having your password cracked by a targeted attack (since, in a targeted attack, there are no other hashes to be collateral damage). Why did you bring it up? What attack are you thinking of?
With an unsalted hash an adversary can do as much work as they want in advance, store output and then trade that in once they have your hashes to get all or most of the same rewards as if they'd done the work after getting your hashes. Rainbow tables are the most famous example, but they're part of a family of similar attacks.
Salt lets you arbitrarily discount this advance work because the attacker must do it for all possible salt values and you get to choose how many there are - the early Unix crypt() salted pessimised password hash discounts it by a factor of 4096, modern schemes often use many orders of magnitude more salt. An attacker who has $4M to attack my password scheme probably doesn't want to spend $4M now to have a $1000 advantage once they get the hashes, and they certainly won't for a 1¢ advantage.
In a single-target attack, I don't really see the concept of "pre-computation to trade space for time". That hurts you by taking a lot of space, but it doesn't gain you any time, because you spent at least the required amount of time, but almost certainly more, doing the pre-computing. If you can buy someone else's pre-computed rainbow table, then sure, that's an advantage for you. But the adversary actually doing the pre-computing is doing it in order to crack many people's passwords all at once ("this table will let you identify _everyone_ whose password is qwe123"), which is the scenario I described earlier.
(At this point I feel I should clarify that "some people use the same passwords" is a real threat and a real reason to avoid md5. I just don't think the comment I responded to, "It is a question of when not if a hash table is fully cracked", was made in good faith or informed by... anything. To fully crack md5 in that way, you'd need an easily-computed function that inverts it. No amount of hashing speed is ever going to get you there.)
In a single-target attack the reason you'd do this is because you expect your target to react in a timely fashion to discovery of some other part of your attack by changing passwords.
e.g. maybe you're sure you can break in to get hashes, but you will trigger a reactive IDS. You figure you have some period of time after that trigger before your target is alerted and changes their password.
Time-space tradeoff lets you avoid doing all the work against the clock _after_ the IDS triggers, instead you can do it all _before_ you have the hashes, and only pull the trigger and set off the alarms when you're ready to quickly break the hash, get in and do whatever your actual attack requires.
It's not a _common_ scenario, but it's important to remember it exists in designing general purpose components like password hashes.
You can assume the system uses a certain salt pattern, e.g. 4 byte prefix or 8 byte prefix or suffix. This can reduce work from full crack to some 40 bit crack. (Guess salt then presume stupid concat scheme, use collision attack to get matches.) That one is doable on a modern PC on a GPU. It is a targetted attack. The mass variant are salted rainbow tables.
You usually do not even have to recover actual password to use credentials associated with the hash.
Even if they had a legacy implementation in MD5, gradually migrating from storing MD5 hashes to storing bcrypt hashes is trivial to do.
https://blog.codinghorror.com/i-just-logged-in-as-you-how-it...
> I found what one could call a security hole in Stackoverflow. I'm curious enough to go digging around for holes, but too ethical to actually do anything with them.
From the second post (the one you linked), where Jeff quotes the hacker:
>>I guess I can tell you, so you don't fall into this trap again. There's a site I help out with that doesn't salt their passwords. They're MD5 encrypted, but if you've got a dictionary password, it's very easy to use a reverse-MD5 site to get the original. I was able to figure out you were a user on the site some time back, and realized I could do this, if only I knew your openid provider...
The "password vulnerability involving unsalted hashes" was on another site. The hacker was only able to gain access to Jeff's Stack Overflow account through a combination of their privileged access to the database for that other site and Jeff's own bad op-sec. The only real security error attributable to Stack Overflow in any way was Jeff's own and had nothing to do with Stack Overflow's infrastructure.
It's a very short hop from email to link technologies from this dataset to place of work and then potential attack routes for a sufficiently capable actor.
https://meta.stackexchange.com/questions/2677/database-schem...
And also all the metadata associated to user's activity
As usual, this is a meaningless statement. It could mean they have full packet captures they've completely audited, or it could just as easily mean "we don't keep logs of any kind so we have no fucking clue".
At any rate, I still have some degree in trust in the people running things over there to tell us if the reality is different.
SO not only do they catch attacks early, in the perimiter network, but they also often block legitimate traffic and handle such cases regularly.
But it's a default deny policy so that comes with. It also costs a ton of money for the best IDS solutions. I believe it comes from companies like Checkpoint, Cisco and Symantec.
(Only mostly joking...)
It seems the vast majority of breach discovery amongst typical companies is an engineer going “hrmm that’s odd”: a router at 100% CPU because it’s currently part of a DDoS attack. A DBA noticing a huge query they don’t recall running. Unusual login times for administrative accounts. Having email systems sinkholed for sending spam. And of course “all my files are encrypted?”
> Finding suspicious outbound network activity
https://blog.rapid7.com/2016/05/09/introduction-to-osquery-f...
Similar to how Stripe handles payments with a token, we could all store tokens for User information (eg the Id) and query the vault (or operate on the vault, eg, validate login, or return email, etc) using keys.
The service could be hardened (like Stripe) to ensure the data is stored securely, and detect ex-filtration attempts (eg, queries for multiple customers at once being abnormal) and automatically block that.
You can rent it from AWS, of course. It's called Cognito.
https://aws.amazon.com/cognito/
You can also offload that responsibility for user data/credentials to Google/Facebook et al as you see many places with "Login with Facebook", making your users pay in privacy-invasion instead of bearing the burden of properly securing your user's PII yourself...
As a user, it seemed like "so i need to login to Google on Mozilla.org... it's just a wrapper for my Gmail and/or Mozilla account?"
Specialize in storing personal data (name, address etc.)
Provide APIs that only allow gentle exfiltration of data. e.g. < 10K queries per minute/hour/day whatever.
Have alternate paths (e.g. manual procedures) when greater volumes are required (e.g. for disaster recovery testing).
Then get it audited to death by some serious security firms.
Or host your own by using Hashicorp Vault.
It's as if a prison disclosed that the front gate was left unlocked for several minutes and they're still counting the prisoners. I would much prefer to hear about it after they have learned whether anyone escaped.
Just hope that you have nothing anywhere that may be of interest or value to anyone, anywhere.
Good luck.
If you sat on a fresh exploit, would you really waste it with automated, untargeted mass scans, which may draw a lot of attention, causing your bug to burn out quickly?
You see these kinds of attacks frequently with cryptolocking/cryptojacking software. The more quickly you deploy an attack targeting a new vulnerability, the more victims you'll have.
How many people self hosting are even qualified to run a secure system? I bet most of them are just regular devs who know just enough about linux to get something online.
Beyond the thing about different types and frequency of attacks - sure, I trust Google's security more than my own. But I do trust my own security more than that of Random-Startup.IO, who likely have no full-time security people, and little incentive to get the job right (paying attention to security slows down your incredible journey).
Also, even with big companies, this argument applies primarily to the few like Google, Facebook or Apple. Your Random Megacorp from outside tech community usually focuses its security efforts on satisfying regulators and neutering their own employees, who'd otherwise happily copy out all sensitive data to make their jobs easier.
Look at the logs for your existing infrastructure. I can pretty much guarantee that there are drive-by Wordpress attacks, regardless of what software is actually serving requests. There will be ssh login attempts.
You gotta realize, it's not like I'm arguing you should set up a server with 1234 as the root password. I'm assuming you're reasonably competent in security, just mostly lacking in the bandwidth needed to e.g. keep your server constantly checked and updated on a daily/weekly basis. With those assumptions I have no reason to think the slightly increased risk of getting hit by a brand-new attack through an IP scan or something is going to outweigh all the entire classes of risks that you do away with as a result of not being part of a massive corporate attack target.
Although, heck, if you're absolutely paranoid about random IP scans, you could just move your stuff to some obscure port, which I'm sure you realize already. There you go, you're not going to be found through random mass scans anymore.
The only thing I miss sometimes is you can't manually add passwords.
What's a "java ghost script"?
And, yes I do close all browser windows/processes before login, and after logout of important websites for instance to make sure cookies and passwords are gone from browser memory.
Correct.
Firefox at least offers you the ability to set a master password to encrypt all the rest.
Your Google Password is also available to Google. (At least every time you log in, even if they properly hash and discarded it after authenticating you and just use a token from there.)
I highly suggest you read chrome's privacy policy on that password sync feature. Hint: when enabled on android the wifi password is unencrypted (or reversible, which is close to the same thing. they claim it must be so to work with wear)
I sync with Seafile over WebDAV.
I sync my phone using Syncthing, so that's one way.
Then again, a password storage solution is probably investing so much more into security that it may be actually better than using something else..
OTOH you're losing entry-level syncing which is quite the inconvenience...
If the OpenSSL debacle taught us, open source and the fact that many people can look at the code does not mean it's actually being looked at. Don't get me wrong, still loads better than non-open source, but you're still face a huge risk. I'm slightly competent as a developer (not that much, just enough to barely get by) and still looking at the code base of the many apps, services and platforms I use, I'm astounded by the fact that I have no clue how they actually work, and if there is any obvious attack vector there. MOST people have even less of an understanding of all these than I do.
You can say the exact same thing for any proprietary software or web service. The point of self-hosting is reducing the attack surface and probability of an attack.
The simpler and smaller the surface of attack is, the better.
But it doesn't matter, the damage has been done over and over. Pretty sure I'm in many leaked database already (Hi Adobe!)
So if you used Gmail or communicated with people who used Gmail before 2013, then a copy of your communications are backuped up in Utah[1] right now.
[0] https://www.wired.com/2013/10/nsa-hacked-yahoo-google-cables