"The most popular password was "123456" (202 of the 4,000),... and 12345 (99)."
It's good to see that the need for longer passwords is getting through to users.
It appears someone closely linked to the hacking gang that ransacked adultery website Ashley Madison has accidentally outed him or herself. Investigative computer security journo Brian Krebs, with the help of pals, today named a Twitter user they believe is involved with Impact Team, which publicly leaked 33 million accounts …
Incidentally, I discussed this matter with Ello around the time they were getting lots of press and they agreed that they would put a limit on how many people could have the same password. The system would simply reject passwords that too many people already had.
Dunno if they actually did it.
This post has been deleted by its author
The system would simply reject passwords that too many people already had.
It should be infeasible for the system to determine this. If it isn't, then the password storage mechanism is vulnerable to offline attacks.
The password verifiers should be cryptographic hashes with substantial salt, which would make it computationally infeasible to compare a candidate (plaintext) password against many existing verifiers in a timely fashion.
How do they tell how many users have the same password, if they're using salts, PBKDF etc and not just MD5 or SHA1? Weak.
If salted hash is used, the salt values for all existing passwords are necessarily stored in the authentication database along with the hashes. So the check for same password simply salts and hashes the candidate with each of them and checks if the resulting hash is already in the database.
rather than comparing against passwords of other users, the comparison should be against an existing password dictionary - i.e. something that both researchers and blackhats would use to brute force hashes which may potentially leak from the database. I say "potentially" because it's the same as with home insurance - you do not want this to happen, you do not really expect it, but when it does happen you are prepared. Although I have to admire that AM used bcrypt, which gave the passwords good protection and greatly reduced the rate of brute force attack on hashes.
>>"If salted hash is used, the salt values for all existing passwords are necessarily stored in the authentication database along with the hashes"
No, that is NOT correct. In fact, storing your salt in the database alongside the passwords would be bad practice. You store it elsewhere and just query the database for the salted hash, not do it all on / within the database. All the database needs is the hash, not the salt.
No, that is NOT correct. In fact, storing your salt in the database alongside the passwords would be bad practice. You store it elsewhere and just query the database for the salted hash, not do it all on / within the database. All the database needs is the hash, not the salt.
In any case, you need to store each user's salt value in plaintext so that you can use it when the user logs in. From this point of view, it is irrelevant if it is the same database, or a separate one for the salts. So all the salt values are available if you want to check if the user's candidate password is already in use by someone else.
>>"In any case, you need to store each user's salt value in plaintext so that you can use it when the user logs in."
This is correct, but the original statement was not. You do store your salt in the database - certainly not in the one that contains your password hashes. So for example, the webserver might have the salt, and it will use that to send only the hash to the database. That way if your database is compromised, the salt may not be. If people are going to use the Boffin icon and correct others, they should get their facts right. It is not necessary to have your salt in the database and is actually a bad thing to do.
In any case, you need to store each user's salt value in plaintext so that you can use it when the user logs in. From this point of view, it is irrelevant if it is the same database, or a separate one for the salts. So all the salt values are available if you want to check if the user's candidate password is already in use by someone else.
All true, but this is precisely what should be infeasible once you have a substantial number of password verifiers. The security value of rejecting a "too common" password - which is very small, if there's any at all - doesn't justify throwing a bunch of computational resources at hashing the candidate password with every salt in the database. That's a dumb use of resources to achieve a pointless objective.
Password-strength restrictions are already a sign of failure: it indicates that users aren't willing to comply with security mechanisms because they see those mechanisms as too expensive for the value they provide. So the user experience is broken or the user doesn't have a clear view of what's at risk (or the risk is perceived as an externality). You have either a user interaction model problem or an economic problem.
If you aren't able to address that issue in any way other than a password-strength restriction (ie you're admitting failure), there are much, much better checks to use than "gosh, a whole bunch of other people used that password".
If salted hash is used, the salt values for all existing passwords are necessarily stored in the authentication database along with the hashes. So the check for same password simply salts and hashes the candidate with each of them and checks if the resulting hash is already in the database.
So you have to read every row in the table and do some computation on it, before inserting your single new row? Nice DDOS opportunity.
>>"So you have to read every row in the table and do some computation on it, before inserting your single new row? Nice DDOS opportunity."
That would indeed be a consequence of what they wrote. Happily, despite some people cheerfully upvoting them, they got it wrong. However as I've been downvoted for correcting them, I like your method of actually proving why it's unworkable. Good catch.
This post has been deleted by its author
Does anyone remember that one of the anti Iranian nuclear program viruses played Thunderstruck at full volume on the infected computers back in 2012. I don't think it was Stuxnet or Flame but another one? Anyone think the hackers could be somehow related to the same group>
https://www.google.com/?gws_rd=ssl#q=virus+plays+thunderstruck
And with numbers that low, you are probably in the territory where a good number of them are sicko men pretending to be women for kicks. So Ashley Madison ends up being like one of those costly Red Light district tourist bars your stag party "crack team" get conned into visiting, where the embarrassed looking clientele are all sad tourists, men, thin on the ground, the drinks cost £100 a measure and the couple of "women" present are weird looking with five o'clock shadow... Allegedly.
Could say more about James and his beer goggles, but what goes on tour stays on tour.
It looks like that every prosecutor in the world would like Krebs as juror or "expert" witness. With hard hitting, incontrovertible evidence as he as presented, we will all need to watch our step.
Note to self - change music to "The Angels" (in particular "Am I ever going to see your face again?") to confuse this genius...
You got problems in your life of love
You got a broken heart
He's double dealin' with your best friend
That's when the teardrops start, fella
Pick up the phone
I'm here alone
Or make a social call
Come right in
Forget about him
We'll have ourselves a ball
Dirty deeds, done dirt cheap
Dirty deeds, done dirt cheap
Dirty deeds, done dirt cheap
Dirty deeds and they're done dirt cheap
Dirty deeds and they're done dirt cheap
Reading this I have to conclude one of three things. Either this Twitter account is a dead-end, well protected and untraceable back to any physical body, someone has set them up to be a patsy or, option three, the hacker is an idiot.
EDIT: I suppose a couple of other possibilities having just had a look at their Twitter feed. Deuszu could just be a fan, playing at being a red-herring. If they and Krebs have a common source for that link then that is viable. Alternately they could be the hacker and are so confident in their concealing of evidence they actually want to "taunt" people with visibility. That would be rather nuts, though. Finding someone who hacked you can be very hard. Finding if a specific someone hacked you, is a lot easier because you can start from the answer and work backwards, as it were.
I was thinking similar things.
I'm sure Brian Krebs is very smart - and I'm no security expert - but I'm not sure he has really "identified" the hacker as such. He might be right about the Twitter handle but that's not quite the same as having a real name and address where you can rock up with squad cars and a warrant. You need evidence and stuff for that.
Still, there's a lot more to play out so let's see.