161–170 of 207 posts
Serious question: what sensitive user data is there on Stack Overflow anyway? Questions, answers and comments are all public, the content is Creative Commons licensed and even available in handy downloadable & queryable form: https://data.stackexchange.com/ 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…
Earlier quoted context omitted.
Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.
How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
Earlier quoted context omitted.
Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.
How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
Earlier quoted context omitted.
Wouldn't this really just turn into a database as a service?
Since it's users, maybe call it a directory... And since it's changing, maybe even an Active Directory? Like this https://aws.amazon.com/directoryservice/ ?
Earlier quoted context omitted.
Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.
How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
I wonder why they are disclosing this so early, with so little information.
Because if they didn't, they'd get criticism about not doing so right away. Also...GDPR?
Earlier quoted context omitted.
> 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?
i use an alias on stackoverflow, and i use an alias here on HN! 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 nam…
Earlier quoted context omitted.
Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.
How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)
Earlier quoted context omitted.
I agree with your thrust that your parent poster (AstralStorm) is barking in a different forest from the tree we care about, but for salting it is also a defence against pre-computation to trade space for time. 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…
A rainbow table is the exact attack I'm saying is still infeasible. ("Strong passwords are still just as strong.") It only works by assuming the victim uses one of a known set of weak, easy-to-guess passwords. If they don't, their hashed password is very unlikely to be in the rainbow table at all, because there's just too much hash space. The calculation in my original comment gives the approximate number of hashes n…
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.
Earlier quoted context omitted.
Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.
How do you update password storage if you don't store the passwords only hashes? 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.