Passwords

Adobe had a little issue the other day with the small matter of 150 million accounts being breached and released to the public. Whoops. So what are we talking about? A shed load of records containing an internal ID, username, email, encrypted password and a password hint. Naked Security did a very good write up on Adobe’s giant-sized cryptographic blunder in terms of what they got wrong with their password storage so I won’t try to replicate that, rather I’d like to take a look at the password hints. This is an interesting one from an application security perspective and the rationale basically goes like this: In order to help people remember their passwords,...

I don’t know how Evernote stored my password, you know, the one they think might have been accessed by masked assassins (or the digital equivalent thereof). I mean I know that their measures are robust but then again, so were Tesco’s and according to their definition, “robust” means storing them in plain text behind a website riddled with XSS and SQL injection (among other security faux pas). Last year we saw LinkedIn breached and some millions of SHA1 passwords with no salt exposed. Last week we saw Australia’s own ABC do the same thing; it took me 45 seconds to crack 53% of those and others have since gone on to crack...

45 seconds. That’s how long it took to crack 53% of the ABC’s now very public password database. That’s more than half of the almost 50,000 passwords that were publically exposed today. How the passwords (among other data) were exposed is yet to play out, but what we now know for sure is that the mechanism the ABC used to protect these credentials was woefully inadequate. Here’s how it was done: Firstly, the dump comprises of 10 parts all listed over on Pastebin. All in all there are just under 50,000 records with the following attributes: user_id user_age user_town user_nick user_regip addedtomap user_email user_...

Last month I wrote about our password hashing having no clothes which, to cut to the chase, demonstrated how salted SHA hashes (such as created by the ASP.NET membership provider), offered next to no protection from brute force attacks. I’m going to assume you’re familiar with the background story on this (read that article before this one if not), but the bottom line was that cryptographic hashing of passwords needs to be way slower. Not half the speed or even one tenth of the speed, it needs to be thousands of times slower. The conclusion of the post was frankly, a little unsatisfying. Why? Because it essentially said “If you take my favourite technology...

Another week, another breach. This time Yahoo! was the target with 453,491 email addresses and passwords from their Voices service being exposed for all to see. Whilst unfortunate for those involved, these breaches do give us some unique insight into password practices and as is usually the case, it’s not pretty. Back in June last year after one of many Sony breaches I conducted a brief analysis and found a litany of bad password practices. Less than 1% of passwords contained a non-alphanumeric character, only 4% actually used more than two character types and 93% of passwords were between 6 and 10 characters long. What made the Sony analysis particularly easy (and relevant) was that there was...

In the beginning, there was password hashing and all was good. The one-directional nature of the hash meant that once passed through a hashing algorithm the stored password could only be validated by hashing another password (usually provided at logon) and comparing them. Everyone was happy. Then along came those pesky rainbow tables. Suddenly, huge collections of passwords could be hashed and stored in these colourful little tables then compared to existing hashed passwords (often breached from other people’s databases) at an amazing rate of knots thus disclosing the original plain text version. Bugger. So we started seasoning our passwords with salt. Adding random bytes to the password before it was hashed introduced unpredictability which was the kryptonite...

No really, this is my LinkedIn password: y>8Q^<6mqKEA4hac Well it was my LinkedIn password until earlier today when it became apparent that LinkedIn had suffered what could only be described as a massive security breach. The disclosure of 6 million passwords used in one of the world’s premier social networking sites is nothing short of astonishing. But what’s also astonishing is that this exercise once again demonstrates that we, as users, are continuing to choose outrageously stupid passwords. How do I know this? Take a look at leakedin.org and try something obvious: And here it is: Now try your old LinkedIn password which, of course, you’ve already changed. Don&...

This content is now available in the Pluralsight course "Secure Account Management Fundamentals" Recently I’ve had a couple of opportunities to think again about how a secure password reset function should operate, firstly whilst building this functionality into ASafaWeb and secondly when giving some direction for someone else doing a similar thing. In that second instance, I wanted to point them to a canonical resource on the ins and outs of securely implementing a reset function. Problem is though, there isn’t one, at least not covering everything I believe is important. So here it is. You see, the world of forgotten passwords is actually a little murky. There are plenty of different perfectly legitimate...

Another week, another major security incident with a significant website. So the news this time is that Zappos – those guys who sell shoes (among other things) – to folks in the US may have, uh, accidentally disclosed somewhere in the order of 24 million user accounts. Bugger. Now of course at the root of this is inevitably yet more evildoers intent on breaking through website security for financial gain, activism or just plain old kicks. Regardless of the modus operandi of these incidents, the fact remains that a significant number of accounts have been exposed and there’s now the real possibility that usernames and passwords – perhaps your username and password – are going to be floating...

I love a good XKCD comic; Randall Munroe has a unique way of cutting right to the crux of technology issues and always doing it in a humorous fashion. Little Bobby Tables remains an all-time classic and it’s amazing how many times you’ll see it quoted in security discussions – it’s now well and truly embedded in pop culture (well, at least in the little app-sec corner of the world). Last week’s password strength comic was no exception; very funny stuff about the pain people will go to in order to create a strong password which they’ll ultimately forget. Anyway, the crux of the comic was this piece about using...