http://www.bbc.co.uk/news/technology-18338956

Quote:

it turns out they used sha1 hashing with no salt keys.

& this is exactly why I am AGAINST using these single login & other authentication systems such as facebook, Oauth, LinkedIn, Twitter & so on.

the truth is you don't know how secure they are, & time & again, these so called secure systems have been exploited & people discovered their hashing was not as secure as everyone thought. DO NOT COMPROMISE SECURITY FOR THE SAKE OF USER CONVENIENCE!!!!!!!!!!

I suggest we seriously consider adding password stretching to ICMS. It's trivial to implement as it just involves rehashing the password hash a large number of times.

Basically it just increases the amount of work required to calculate the password hash, greatly slowing down offline attacks to the point where they becomes painful or infeasible to do.

well that's definitely on the cards, I already have a better method of securing passwords utilising existing method with improvements, 1 of those is using stretching. I know of 1 flaw in the system we use (though i'm the only 1 who is aware of that, I will share that info with trusted devs providing we use either OTR encryption on MSN or use GNUPgP encryption on emails).

the biggest job is implementing it & being able to do the pass expiry. But i've already figured out a way of doing that.

When relying on a third party for some data, there's the risk you have to evaluate whether that party can be trusted with the type of data you share with it. Unfortunately, it's not because you are a big site that your procedures and developments are the best. That's what happened here with Linkedin, a major flaw in their security.

We won't be able to stop users from using that kind of services to login (Twitter, Facebook, OpenID, heck, even LDAP if it's on a hosted server somewhere else), but we can make sure that the services WE provide are the most secure possible.

It's clear that any idea around raising security even higher than we already have, will be looked at with big interest. Not only by the team, but also by current and potential users. I'm interested to see what you come up with Vaughan

The next story is last.fm with more than 2,5 millions accounts, all with unsalted MD5 hashes ==> OMG !!!

If you have an account on LinkedIn, you can check if your password was leaked/cracked - http://shiflett.org/blog/2012/jun/leakedin

If you haven't changed your password yet, I'd recommend changing it before checking to see if it's on the list. I trust the site link above - Chris Shiflett is a well-known and trusted PHP developer and blogger on security issues.

How do we respond to this, as a community-focused system? There are 3 parts to all of this - authentication, authorization, and cryptography - and we need to address them all.

Authentication: establish identity
Authorization: grant privileges
Cryptography: encrypting, hashing and hiding sensitive data for transmission and storage

Logging into a website uses all 3.

@madfish has explained some of the principles of this in the documentation for the Yubikey module - the basics of authentication are in knowing or having something unique. 1-factor authentication only requires one or the other. 2-factor authentication requires both.

The sites that were recently hacked failed because they had poor cryptography. 2-factor authentication would have reduced their risk dramatically, as would better general programming.

In all of this, we have not talked about policy - another major factor in the security of any system. Recommended read - http://www.schneier.com/blog/archives/2010/11/changing_passwo.html It talks mostly about password rotation, but covers some good points about having passwords appropriate for the content they protect.