Earlier today, the hacker collective Lulz Security released a batch of 62,156 email/password combinations from unknown sites; I decided to take a look at the data and see if there was anything to be learned from it.
So, let’s take a look at a few stats:
Total Domains: ~5,230
Top 15 Domains:
There are over 50,000 unique passwords, but even with this many passwords, there’s still a few quite common – and very bad passwords in use:
While this is a fairly small release, the LulzSec twitter stream has a number of entries like these:
There are several tweets about people accessing Facebook, Twitter, and even Amazon accounts – what’s so unfortunate here is that service providers could easily restrict accounts on lists like this to protect the users and greatly reduce the impact of these breaches.
Until people learn that password reuse is dangerous, this will keep happening.
Update: I’ve removed a link to a tweet, as the account has since been removed. The tweet said: “@LulzSec Cheers for the paypal account with £250 in it! ;)”
I recently became curious just how much time I had spent working on content for this site, which led me to an idea: it would be great to have a page that listed some useful data about the content, and how much effort was put into it. I had some hope that I could pull some of this directly out of Hugo, though unfortunately it didn’t expose the information I wanted (and certainly not in an efficient way).
Anyone working in application security has found themselves saying something like this a thousand times: “always hash passwords with a secure password hashing function.” I’ve said this phrase at nearly all of the developer events I’ve spoken at, it’s become a mantra of sorts for many of us that try to improve the security of applications. We tell developers to hash passwords, then we have to qualify it to explain that it isn’t normal hashing.
(See here for another issue discovered during this research; Updates over HTTP & Command Execution.)
PL/SQL Developer by Allround Automations has an option to store the user’s logon history with passwords – the passwords are encrypted with a proprietary algorithm. At this point, you should know how this is going to go.
For those that don’t know, PL/SQL Developer is a tool for developers and database administrators to access Oracle – an essential tool in many enterprise environments.
There are two ways to implement security:
Real security, based on empirical evidence and analysis. Checklist security, based on the latest checklist somebody says is important. When security is based on real evidence and analysis, policies are enacted based on real gain and measured against the business impact. Risks are considered, and the costs versus benefits are well understood so that policy choices are based on real, useful information.
On the other hand there’s security by checklist.
Today ZDNet published an article titled “The lunacy of trying to avoid NSA spying by moving e-mail and cloud out of the US” – I’m still trying to figure out if the position is naive, or intentionally ignores important facts.
In short, the author (Steven J. Vaughan-Nichols) states that your data is safer in the US because outside of the US, the NSA has much less restrictive rules to operate under.
