Jeepers, I just changed my linked in password. I had the source for PGP back in 1993, I don't recycle passwords for anything remotely important, I use gnarly long passphrases, two factor authentication and what-all else, and I AM SICK OF IT. I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops. I'm tired of the maintenance security imposes on me, the lack of a meaningful industry certification, and on developers' insistence that I use passwords of between X and Y length and containing particular combinations of characters, numbers, etc.
Every time I read about one of these avoidable breaches, I feel tempted to gin up a class action lawsuit and force a company to either write a painfully large check to acknowledge the time and trouble it has imposed on its customers - say, about $5 each - or sell itself to its users in lieu of money. I'm not actually going to go to that effort, but sooner or later some enterprising law firm will, and I'm sure everyone here is going to be all hand-wringy about it.
We need to automate security and make it customer-centric. It is plainly too complicated to be left to individual web service providers, just as brick-and-mortar stores do not manufacture their own door locks or burglar alarms. Vendors, if you feel you can't safely outsource this job to a third party, then you need to hire full-time security monitors and start facing up to security as a line-item cost rather than a check-box you can forget about after you've put it in place.
Sorry to be ranty, but when established firms are losing millions upon millions of passwords literally on a daily basis, something is drastically wrong with the state of the art. This is a problem that can't be prettied away with CSS or smoothed over with a few tweets and blog posts.
Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.
It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here to provide a subject for you to point your finger at should there be a breach".
Many banks are encumbered by old mainframe systems that still do a lot of their computing. I don't know how much of that bubbles up through to the web interfaces we deal with, but I know many tellers and agents are still on green screens, or on interfaces that are just pretty wrappers to mainframe terminals.
I've heard that excuse from banks and such before, and, frankly, I suspect they are lying.
Oh, I fully believe that whatever ancient mainframe they are using might limit passwords to some small number of mono case characters with no funny characters allowed.
However, that would only apply to passwords for mainframe accounts. The bank is NOT going to be creating a login account on the mainframe for each bank customer. Our bank accounts are just entries in an application database on the mainframe.
If there is some kind of per customer password that the mainframe stores with the bank account data and that the online system has to provide when sending transactions to the mainframe, and it has such a limit, and the bank cannot update the application and database for some reason, that still should not be visible to the customer doing online banking.
The part the customer sees online should have its own password database, which allows good passwords, and in there it should have (encrypted!) whatever the ancient limited mainframe password is for that customer's account.
Unless the web interface itself runs on an ancient mainframe, I strongly suspect that there is no acceptable excuse for only allowing short passwords from a limited character set.
Banks are simply not very good at security, or they don't care. Hell, they insist on mailing me things that include my full credit card number, ensuring that someone who wanted to inconvenience me just has to drive by my mailbox at the right time and steal my statement. How freaking hard would it be for them to X out all but the last 4 digits. Yes, that would mean someone whose statement covers multiple cards might have a collision--so don't issue two cards with the same last 4 to two people who receive a joint statement.
The reason they don't allow special characters is to prevent situations where the customer has forgotten his password and needs to go through an excruciating verification process to access his own account.
As someone that penetration tests a lot of banks it does sometimes make it's way through. Larger and more established banks (at least in EMEA) sometimes tend to use highly distributed systems that all interoperate in very strange ways, which can sometimes lead to interesting results on web application penetration tests (e.g. there's no data store, so no SQL injection but there'll be some obscure pre-relational data store you can inject right into if you only know how to talk to it).
It's not that easy to get rid of either, the banks have to support internal applications that expect things in those formats, as well as all the unofficial apps that plug in via messaging systems and may not be aware of the other app from either end.
At last Chase allows us to have rather long passphrases (mine is well over 16 characters). Discover has the same alphanumeric-only rule, but limits you to 10 characters. 10. Then we have the silly little sites that don't retain any important information aside from a contact email that force you to have high entropy and two-byte non-latin characters in your password. (OK, so that's an exageration, but not much of one.)
Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.
Special characters don't make as much of a difference as password length: http://xkcd.com/936/ (a comic that must appear on any password-related thread). According to the XKCD analysis, an 8 character password based mostly on letters with some numbers and symbols has ~28 bits of entropy, while a random four word password has 44 bits. [Edit to add: http://news.ycombinator.com/item?id=4083381 claims over 3 billion MD5 hashes a second for $1000, meaning your 28-bit password could be cracked effectively instantaneously by a high school kid buying phishing gear with stolen credit cards or a summer job].
If you're an international web site, it might make sense to disallow symbols, as your customers may not be able to enter their chosen symbols when traveling internationally.
The short XKCD password is based on a dictionary word, making it vulnerable to intelligent brute force (oxymoron of the day).
I imagine the calculation goes something like this:
1/50000 Likelihood of a particular uncommon word
1/8 Substitute up to three letters for numbers
1/2 Initial capital or initial lowercase
1/32 Add a punctuation character at the end
1/10 Add a digit at the end
1/2 Possibly swap punctuation and digit at the end
----------------------------------------------------------
1/512000000 Resulting probability
-28.93157 log2(1/512000000) -- number of bits of entropy
So, if e.g. XKCD assumed only 25000 uncommon words to choose from, that would give ~28 bits of entropy.
Thanks for the thorough answer! I originally missed the part about using a real word as the base.
For my passwords, I use 8 character random strings so hopefully I am a little safer. Although, as I'm learning from all of these password leak debacles, you are only as secure as the systems using those passwords.
I also have Chase and have heard the explanation for not allowing symbols in passwords to be that they are harder to grep out of logs if someone is keylogging you. Seems like BS to me, but either way is is extraordinarily frustrating to not be able to use a strong password for your bank.
Something even more ridiculous Chase does is assign a default pin of '3210' to checking accounts.
My (German) bank only allows passwords up to 5 characters.
When I ranted about it on twitter some IT guy from a local branch commented about that is totally enough since they do an hour lockout after 3 wrong tries.
o Your German bank may have your password stored in an Utimaco/Sophos Hardware-attack-resistant keysafe, not hanging out in some linux hash file.
o If they lock you out after 3 tries, and the keyspace is [a-zA-Z0-9] - that's 916,132,832 combination, and only three attempts to get it right before being locked out.
On the surface, it sounds much less secure, but, depending on their procedures and hardware, it might be significantly more secure than a 9 character password that goes into a hash file that is software accessible.
Of course - better case - is a Hardware key safe that lets me store my 30 character 1password random password.
I receive spam (not marketing crap, but pump-and-dump penny stock fraud spam) at an email address I created only for use at TD. Either they sold their email database to spammers, or they got hacked and failed to disclose it.
> I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops.
MythBusters looked at fingerprint scanners in episode 59, "Crimes and Myth-Demeanors 2". They were able to easily bypass both the cheap consumer models and an expensive professional one with advanced features that supposedly check for body heat and a pulse to make sure you aren't using a fake finger.
Another problem with biometrics: it allows unapproved sharing of identity information. If I use a fingerprint or iris scan or some such to identify myself to entity X and to entity Y, then even if I'm using different names with X and Y, they could compare biometric data and correlate my identities.
All they needed was a photocopy of your thumb-print that was licked, stuck to your thumb, and applied to the scanner. If it was 'warm' enough and had some kind of pulse, you were in.
The "Jell-O finger", made much the same way, using a standard electronic board etched to make an inverse thumb-print also worked freakishly well.
On the other hand, it's much harder to crack a hashed thumprint image.
[edit]
evan_ is right, you don't hash scan images. The question is, how much usable bits of entropy you can extract from a thumbprint scan? Anyway, I retract my main point.
Definitely. A 256 x 256 pixel grayscale image (8 bits per pixel) is half a million bits of entropy... try cracking that on your botnet!
Although the real entropy of thumbprint images is likely to be much smaller, considering that they share many simliar pixels... but it's still unimaginably huge compared to a short alphanumeric password.
Draw a picture on a piece of paper. Sign it, write your name, arbitrary words, whatever. Hold it up to a camera.
Could something like this be made to work? Work in the sense that a variety of cameras could read the same "password"? I guess QR codes have a fair bit of redundancy built-in...
And the 11th time? I think I've had significantly > 10 sites I use have major password leaks. And I just turned 26 - my 10 fingers (ok, 20 with toes) would need to last a lifetime for this to be a viable solution.
I'd be more concerned about government mandated fingerprinting. Using public key authentication, it would be possible to make biometric keys nigh impossible to steal (such that they don't ever exist on disk in any form whatsoever.) However, they're really easy to steal if you can ever get physical access to the person or any personal records that happens to record said information.
You can get rid of a huge amount of password-related frustration by using a good password manager (not the rinky-dink ones that browsers come built in with).
I've been very satisfied with 1Password and I can't imagine going back to not using it.
I've just spent the last couple of hours creating unique longins for every site I can remember having a login for and storing them in Keepass (opensource password safe). The Keepass database is stored on my dropbox account so it's automatically synced to all machines / devices I use.
I get the impression this is going to be a bit of a PITA, but with the rate these sites are being breached it's probably a sensible move.
FWIW, I did this a few years back (with 1Password, after having used Password Gorilla for a while). With the browser integration 1Password (and, I think keypass and lastpass) use, I think it's actually a productivity plus rather than a PITA...
Concur: I use 1password and lastpass. There are a couple of critical accounts that are actually wrong in each (non-overlapping) and a couple I still only have in my head, but overall it's a huge plus on a day-to-day basis. And it's an incredible relief to read these announcements, pull up my password for that site, and see it's 20 random characters that I know aren't useful on any other site.
Yeah, my three internet banking passwords are in my head only, as are my two dns registrar accounts - they're all 5-6 word passphrases (with non grammatical capitalisation and punctuation) for memorability. The email account that all those accounts send password resets too is two factor authenticated and not used (or published) anywhere else. (I've got hints about these phrases stored in 1Password, but not the passphrases themselves.)
Everything else is 16char upper/lower/digits/punctuation randomly generated by 1Password (except where I need t back that down for sites/services that wont accept that length/charset).
I've also got my random 16char AppleID password in my head, since I end up entering that often enough into place 1Password can't autofill.
I _think_ that's "paranoid enough" at least for now.
One thing I'd like 1Password to do, is bug me about passwords that haven't been changed in some (configurable per login) time. I'm pretty sure in 2 years (or less) I'm unlikely to consider 16char passwords "long enough".
I'm not really knowledgeable enough to rate different solutions, which is why I resorted to ranting rather than articulating a good alternative or working on one myself. Security is something that I have to do rather than something I am personally excited by, and I don't actually want to be encrypting everything for the same reason that I don't want to live in a bank vault or build a ten foot wall around my property.
I guess what I'm saying is that I will pay for a frictionless system whose operator is prepared to place a cost on failure, same way that I am willing to pay for a decent padlock or mortise lock for my physical property. It doesn't have to utterly impenetrable, but I would like the security provider to have skin in the game.
I thought openID was an excellent idea; I'm not sure why it didn't take off, maybe Google took too much of a monopolistic approach or something.
Is there a cryptanalytic reason why a company that has a database full of MD5/SHA1 hashes can't perform a one time upgrade by computing bcrypt(salt, the_old_hash) for every hash they have in the database and then when someone logs in do bcrypt(salt, md5/sha1(password)) to check the password?
That's a perfectly reasonable approach — we did that at PBworks a long time ago. Totally transparent to users if done right. You can also declare password bankruptcy and zero out everything. That forces password resets for your entire user base. The latter approach doesn't go over so well with users or support staff but it is much simpler.
That's what I did when I migrated our application to bcrypt some time ago.
I had some questions about whether using an md5sum as the bcrypt input, with much less keyspace (only hex characters) had any impact on security but nobody could/would answer.
I'm guessing that knowing that the plaintext for the bcrypt hash is always going to be 16 characters of 0-9,a-f might have some impact on crypto analysis but considering the passwords most people use I'm guessing it's only going to be a net win in terms of entropy.
Yeah sure, bcrypt(salt, md5/sha1(password)) is in general less "secure" than bcrypt(salt,password)#, it's still more secure than md5/sha1(password).
# Note though, that you need at least 20 printable ascii chars to get the 128 bits of entropy possible in an MD5 hash, so for _most_ passwords, you could optimize your cracker by only bruteforcing bcrypt(salt, md5/sha1(password)) using shorter strings as password guesses rather then needing to bruteforce the whole 128 bit MD5 space. With bcrypt and salt though, that turns into an "only practical for state-level attacker" I think.
I've been wondering the same thing myself recently. I know of a number of legacy systems that could do with this but I'm unsure of how cryptographically safe it is (bcrypting md5. Would love if someone with knowledge in the area could confirm that it's ok.
Last.fm sounds like the canonical example of a site that where it makes absolutely no difference if your password gets exposed.
Worst case, some malicious individual on the internet will learn that I still like the Beastie Boys, even though it's not 1994 anymore. And possibly they'll listen to music in my name.
This is why one has a throwaway password. For throwaway accounts at throwaway sites like this. Getting your throwaway password thrown away should by definition not be something you worry about.
It matters because there was a failure and it could be in a technology or service you also use.
It matters because many users re-use credentials.
Scenario: You send a confidential email to a colleague, colleague has her lastfm compromised. Attacker scripts up logins against all common sites - including her Gmail account where you sent your confidential email. Script not only logs in and changes password, it also forwards to her friends and family all the emails containing some target phrases - including your confidential one.
anyone care to bet everyone with a linkedin account who works at a tech company just got targetted attacks? Hi, my name is Joe Hacker, and I work at <domain name>! Since you got my linkedin account, why not try that password at admin.<domain name>?
Anyone who uses the same password for their linkedin and company account earned their punishment for intentionally violating their company's information security.
Protip: Whenever you are evaluating a system and there is an unacceptable failure mode and your answer is "let it fail, then blame the user", go back and find a different answer.
I have over 150k songs scrobbled to Last.FM and have been a member since 2005. I actually can think of very few other services that I would care as much as if my Last.FM was compromised/deleted.
Same. 127k songs since '05, and I still cruise through the site regularly and look at what i was listening to on this day in 20xx.
I briefly paid for the site's radio functionality before it was crippled. It feels to me like they've died a similar death to Flickr (acquired, core team left, innovation stopped). Such a shame.
Agreed. Last.FM is such a trove of data. It is fascinating to see what I was listening to and when, and especially looking at macro events and seeing how that influenced the worlds listening habits.
It took Last.FM until 2012 to implement the ability to find your friends from Facebook. Seriously. It really is such a shame; they're a service that needs to be spun out.
Their event listings used to be my go-to place to find out about concerts. The problem is they have a bug they've never fixed (after at least 2 years) where you can't see events happening on the current night. I think it's related to timezone, and the fact they are based in the UK.
Now I've got songkick, which kicks ass at keeping me informed about shows. But the whole reason songkick is so effective for me is that I imported my listening history from last.fm when I first signed up.
29k since September 2004, and I listen to an album almost every day.
You're scrobbling songs during your whole work day, right? I disable it at work, since I don't pay much attention and end up with lots of plays I don't care much about.
I am listening to music all the time. I have it hooked up with all of the mobile services I've used (Spotify, Rdio), SoundCloud, and online radio services that support it in addition to regular old iTunes and Winamp on my computers. I'd say I listen to the equivalent of 3-4 albums per day. There's a lot of random one-offs that get tossed in there, but there have also been months where I either turned off the service out of embarrassment over something I wanted to listen to and forgot to turn back on, or just plain didn't download it or sign into it through another service. I figure that the fluff evens those times out.
Not only will they be able to listen to music that I like, they might be able to download MySQL as though they were me or comment on Engadget articles as me.
None of which are particularly concerning. Because those are throwaway accounts for me.
Make sure you've got a process in place to at least semi-regularly audit your list of "throwaway accounts".
A long time ago, I signed up to PerkMonks for some unimportant reason. Since it was unimportant then (and still is now) I used my then-standard "throwaway login". Sometime later, and before it became "a thing", I signed up for this new "microblgging service" using my "throwaway login" - it was called Twitter - nobody much had heard of it back then. Fastforward 3 years or so… Twitter had become, while not _important_, at least a place where I consider my personal reputation is important. Shortly after the PerkMonks user database got exposed (with it's cleartext passwords! facepalm!), I got an early morning text message from a friend "Acai berry spam from your Twitter account! Ha ha!" (Thanks Colin… For both the heads-up and the deserved ridicule)
If you're using the same "throwaway" credentials in a bunch of places you consider "unimportant" - make sure you upgrade those to properly secure credentials when the importance of those places changes.
Or better still, get 1Password/KeyPass/LastPass/WhatEver and stop doing that…
Even if you don't use the same username, if they have your email, those are fungible with usernames on many sites. (And of course game over if you use the same or similar password for Last.fm and email.)
But how many people have throwaway passwords on sites like these? It might not mean much to the tech-savvy community, but I'm sure a lot of people use the same password for a lot of services.
They might not be able to do much with your account on Last.fm, but they have your email, for which you may or may not use the same password.
Well, the problem here is that big corps are doing obviously-wrong things with user data. It's not like there's any uncertainty in the industry about how to do things correctly, it's just that these corps and many others are deciding not to.
What makes you think they would make better decisions if the technology was called something other than "passwords"?
There is no technology that cannot be ruined by ignorant implementation.
Passwords suck for other reasons. This is a poor example.
As silly as it is, it's what I'm doing for a lot of my non-essential sites. Being able to see who I've signed up with is also nice, as I'm sure I'm signed up to a whole host of sites that I have zero memory of.
That, and Facebook supports two factor authentication and (hopefully) isn't leaving their pw db as unsalted md5...
I like using OpenID. I just use my domain name as a delegate and point it at my current OpenID provider of choice for authentication (which is currently my Google profile; used to be myOpenID 'til they went down for 1/2 a day). As long as I retain my domain name, I can control authentication, even if my current provider were to be compromised (just point my domain name/delegate at a different provider).
The problem, of course, is a lot of sites still don't support OpenID.
TLS does allow client authentication using keys. It is a flawed solution as it puts too much importance in protecting the key. What happens when you need to login from an internet cafe? How do you securely move keys between devices? What happens when the machine has malware that steal the keys?
Good security assumes that everything can and will be compromised and provides defence in depth. Client certs do little to help.
That problem is pervasive with any sort of private key system, as well as the password databases becoming popular.
Private key files pose a challenge, absolutely. But is it so much worse than having every company Jack store passwords in $non_crypto_hash_system?
(begin-rumination....
Right now, compromise risk for credentials typically lies on the companies. They frequently fail in protecting these credentials. However, your credentials are - inadvertently - distributed out between multiple companies. When one goes down, the other credentials are considerably less affected.
(More so if you've been bad and used the same password everywhere).
Examining a local store, we centralize risk onto the local desktop. Suppose that in order to log into the user's central system, the user had to provide a password. (Example: gpg-agent). Then, to log into a remote system (web, ssh, etc), the user's credentials get passed into the remote system via some well-known private/public authentication scheme.
Points of failure here:
- user forgets own password. All credentials are lost until they manage to get reauthenticated into the system.
- Malware hacks the user's keystore and uploads private keys to $malware_database. Case 1: in-memory hack. Case 2: hacks system database.
- Case 3-ish. Malware injects dialog requesting system password and gullible user enters it. Upload commences...
I am sure other scenarios can be imagined. In these scenarios, the risk is shifted from the company onto the user (and the key storage engineers).
I can imagine that password forgetting would be heniously problematic and cause PR disasters: many people don't like to take responsibility)
Perhaps a possible solution is to generate a private key in the browser using an algorithm such as PBKDF2 or bcrypt operating against a public per-user salt and a high entropy password. The private key is only kept in the clients memory long enough to sign something for the server.
This is not the best possible solution but I can't see how it would be worse than a compromised salt/bcrypt hash.
It would be very foolish, but I do wonder if they used Hadoop to compare their hashes with publicly exposed hashes after breaches of other sites (for example, Gawker or Zappos) in order to force reset affected users.
Apparently this breach is a year old, so nothing to do with it. Maybe they just decided to go public today hoping that focus would remain on LNKD or (even better) people would just think "ah well, it can happen to everybody".
Nice to hear. I had thought that perhaps one of their higher-ups had used the same pass on LinkedIn as on Last.fm and had noticed suspicious activity. Now I know that they just googled to see, "oh, did anyone hack us? they did?! OVER A YEAR AGO?!"
Here's the method I use to manage website passwords: For logins that I don't really care about that much, say last.fm, I use my standard medium-strength 6 character password with a number and a capital letter, something like jfi3Jo. I can remember it because I use it often. For logins that I do care about like my email or bank I salt my base password by inserting three characters from the site's domain name into the front, middle and end of the base password. For example, my login to Hacker News would be yjfic3Joo, where yco from ycombinator.com is added in the front middle and end of the base password.
I know it's not the most secure method in the world but I think it is a good compromise between remembering the passwords and providing a unique-per-site decent strength 9 character password. If someone figured out my scheme they could get into all my accounts but in order to figure out my scheme they would have to brute force crack two of my 9 character passwords from hashes from two different sites and then match up the two accounts and compare the differences, that is the risk I currently take.
It is OK to suggest users to change their passwords, but shouldn't they stop sending their session cookies over plain HTTP? Session hijacking is now widespread and an easy way to get into non-important accounts and then escalate to more interesting accounts.
PS: I'm leaving this comment without any reference to the site name, so I can copy and paste it verbatim in the future; it looks like this kind of breaches will not stop soon.
PS: I'm leaving this comment without any reference to the site name, so I can copy and paste it verbatim in the future; it looks like this kind of breaches will not stop soon.
Be aware that there is the possibility[0] that HN's (or other sites') anti-spam features may detect a copy-pasted post as duplicate or artificial content, and kill it and/or your account. It's probably better to add a link to the original post, with some article-specific text.
[0] Based on speculation and inference, not actual knowledge.
Looks like passwords need to be replaced with something else, obviously most companies, excluding none, are completely unable to handle them properly. Time for a big disruption.
I doubt my new password will be any safer, so I can't really use one which follows my current pseudo-random patterns.
I'm now convinced that password managers, with random generated passwords, are the way to go. At least they have a strong incentive to focus on protecting user data. Still scared of not knowing my own passwords, and giving them to a third party, though.
Agreed, I would never trust my passwords to a private third-party with closed code-base. And KeePass still seems a little meh, especially regarding device support. So for now I'm using an encrypted file synced with DropBox.
To be 'fair': when Last.fm first launched, md5 was probably 'state of the art'. I mean take a step back, they have been around for like forever.
The question is: How would you go on about moving your user database from md5 to a more advanced algorithm? Validate a user's password on log-in and then encrypt it with the new, more secure algorithm?
Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else:
_______
Password upgrading
When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented.
So it would be trivial for the big sites to have switched transparently to a safer hash, even if MD5 was Ok when they started. You could also add salts in the same way, if you were storing unsalted hashes.
In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.
Couldn't you just move from, say, using MD5(password) to bcrypt(MD5(password))? So when it becomes apparent that the old hash is no more secure, start using the combination of the old bad hash (MD5) and the new good hash (bcrypt). This way you can simply run once through the password database, hash each password hash there with the new better hash, and throw away the old hashes. No need to prolong the process until the users log in.
They have some older APIs that depend on MD5(password) being used directly, to compare against auth credentials or to derive other hashes to verify API requests.
Though older APIs they're still used by many older or infrequently updated clients, such as hardware devices with sold with Last.fm integration.
Unfortunately, the longer you've been around the more likely you are to develop dependencies that make it more difficult to upgrade your password hashing.
A new site can do whatever it wants with password hashing, but it becomes harder for older sites with more legacy dependencies to make that kind of change and Last.fm has been around for almost 10 years.
This isn't to say "MD5 is cool, don't worry", but to try and illustrate some of the reasons behind this.
As hashing functions aren't injective, composing them leads to a reduction of range (ie, a smaller set of possible output values). As such, (bcrypt . MD5) would almost certainly be a weaker hash than bcrypt alone. Might not be enough to make a difference, but I'd consult a cryptologist before betting on that.
Yeah, it would be weaker against a collision attack. But that shouldn't be a concern as the purpose of the password hashing function is to protect against a preimage attack: finding the password given its hash. I can't see how the composition could be more vulnerable to a preimage attack than its parts. (Provided that the inner function's output is evenly distributed.)
Great feature. So you alter the password field (extending the length) if needed and when a user signs in it gets auto-updated and Django always tests both/all specified algorithms? Or do you have to add a new database field when moving on? (Sorry for my tl;dr behaviour but while I've got an expert on the line anyway...)
I'm not an expert in any sense, just a Django user. I've never actually looked under the hood, since it just works.
You specify an order of the hash algorithms, putting the one you want first. Switching to bcrypt for me was just a matter of moving it up a few lines in a list.
The password field can probably stay the same length, since it is a hash value anyway. I'm assuming you have a second field that stores the hash algorithm used. When it logs you in, it uses the current algorithm to authenticate you. Then if that technique isn't first on your list, it creates a new, salted hash, and stores both that and the new hash type in the database. Nice and slick.
Unsalted was not "state of the art" in the 1970s. The database would be far more secure if it had used a weaker hash with salt.
To migrate, Unix-like systems generally support database migration through a modular format (see "man pam_unix" and /etc/pam.d/passwd). The next time the password is changed, the field that looks like $1$<salt>$<md5hashedpasswd> will be converted to $6$<salt>$<sha512hashedpasswd>. I guess you could change it at the next login if you allowed modification to the password table during login. If you were eager, you could just salt and rehash the hashes current hashes. To check that password, you would do the old unsalted md5, then apply the salt and sha512 (or whatever) before checking in the database.
You are right, I just meant to say that the 'awareness' has increased a lot since Last.fm first stepped on the scene. Unless you were already security-savvy and had a hacker (as in the original sense of the word) background, I guess no one really cared back then.
On a sidenote, I just changed passwords for what was probably my second last.fm account and I haven't logged in or 'scrobbled' since 2007. Different times for sure.
I don't believe straight unsalted MD5 was ever state of the art for password hashing. Yes, it was a state of the art cryptographic hash at one point, but those are not the same thing.
I just changed my password and deleted my Last.fm account. Just because I changed my password doesn't mean a new MD5 hash of my new password won't leak tomorrow. If you can't trust the service, don't use the service.
To delete your Last.fm account, go to the "Data" tab in settings. Click on "Delete entire account for user".
There's a great deal of room for improvement in password protection, which would make stealing a password very difficult. Some discussion on developments in that front here: http://news.ycombinator.com/item?id=4047968
News of this kind make me even more glad that I use random generated passwords for every site, with LastPass to manage all of that. (Waiting for a snarky comment about LastPass being supposedly hacked some time ago.)
Every time I read about one of these avoidable breaches, I feel tempted to gin up a class action lawsuit and force a company to either write a painfully large check to acknowledge the time and trouble it has imposed on its customers - say, about $5 each - or sell itself to its users in lieu of money. I'm not actually going to go to that effort, but sooner or later some enterprising law firm will, and I'm sure everyone here is going to be all hand-wringy about it.
We need to automate security and make it customer-centric. It is plainly too complicated to be left to individual web service providers, just as brick-and-mortar stores do not manufacture their own door locks or burglar alarms. Vendors, if you feel you can't safely outsource this job to a third party, then you need to hire full-time security monitors and start facing up to security as a line-item cost rather than a check-box you can forget about after you've put it in place.
Sorry to be ranty, but when established firms are losing millions upon millions of passwords literally on a daily basis, something is drastically wrong with the state of the art. This is a problem that can't be prettied away with CSS or smoothed over with a few tweets and blog posts.