MySQL.com hacked via... SQL injection vuln MySQL.com was hacked over the weekend via an attack which used a blind SQL injection exploit to pull off the pawnage. Hackers extracted usernames and password hashes from the site, which were subsequently posted to pastebin.com. Any easy to guess login credentials could be easily extracted from this data using rainbow tables …
You're joking. The HTTPS certificate expired a month ago? Well, I just checked it and you're right: Firefox gives me an Untrusted Connection warning with:
"customer.mysql.com uses an invalid security certificate.
The certificate expired on 2/27/2011 6:59 PM."
It's a measly two-year certificate.
Oh, if you go to mysql.com, there is no concerned warning telling you that your credentials have been hacked.
Coming so soon after the PHP Wiki hack, this is really sad...
It shows a company/server is not managed at all, all in "auto pilot". As we speak about Oracle, money can't be a problem, it is the management who doesn't understand what kind of a message it sends to outside.
Remember hotmail forgot to renew their domain and a linux hacker, feeling pity for the end users renewed it for them?
These are number 1 and number 2 software companies on this planet. Tells a lot about where the IT would be today.
Why is it sooooooo easy to match hashed passwords using rainbow tables? Doesn't anyone implement "salt" (salting) of hashes?
All the systems we install for customers have username/passwords stored as SHA1 hashes of username+password+salt where 'salt' is an installation or site-specific string hidden elsewhere in system configuration. This means that even if you read out the usernames+hashes from the tables you can't necessarily get the password from it...
Mike
We cache the hash of the hash of the encrypted salted input, unhashing the cached hash gives you a hash, unhashing that hash gives you an encypted string, decoding that gives you the salted input, but our salt is a method not a constant, so you need the secret recipe.
All this to protect frickin' car insurance quotes.
*sigh*
The salt doesn't need to be in any way hidden. As long as it differs enough from hash to hash (and in the case stated it *must* be different from hash to hash as it uses the username) it serves its purpose which is to avoid collisions.
By hiding the salt it adds another layer of pain, however once discovered, the salts still do their job as designed.
Using a salt renders any 'rainbow tables' completely useless, therefore it is not trivial to automatically extract plaintext passowrds from their hashes in the database.
Also, if the designers of the system have a brain, the salt value will be stored in a file and not in the database itself. To get the salt value would likely require a totally different entry point for the hack. It would most certainly NOT be exposed by a database injection exploit.
Even if the salt value itself is compromised, a new rainbow table would have to be created specially for that particular salt value. While not impossible, it is significantly more hassle and more computationally expensive than using a pre-compiled rainbow table.
Oh, and it is worth noting that Grendel did not actually reveal what his salt value is.
"Using a salt renders any 'rainbow tables' completely useless, therefore it is not trivial to automatically extract plaintext passowrds from their hashes in the database"
Rainbow tables were rendered useless when people discovered you can do this with a GPU. Amazon conveniently puts GPU boxes in their cloud for anybody who wants to break this stuff at extreme speeds.
Honestly if you care you'll sha512 with like a billion rounds or use whirlpool or something, if you don't you'll just md5() your shiz. md5() isn't bad in and of itself - it just won't stand up to much scrutiny, it's just means you need a lot of trust in your data security because if it leaks out you're screwed.
But.. as with the Gawker hack, having an insecure password on a trivial system is not really a problem. How many people give a stuff if their mysql.com account is hacked? The key is different passwords for different systems.. if the back-end system isn't secure that it probably doesn't matter how good your password is!
Instead of passing an SQL statement to the end user app, which fills in some place markers and then the entire statement is loaded back to the server. How about designing a system where it's impossible to run such remote scripts. Is there any other method of providing such functionality?
prepared statements are pretty close to what you want. They allow you to write up the SQL statement, and sent it off to the server, then you just call that statement later and send the variables for it. Because the variable-values are kept separate from SQL, it's (AFAIK) immune to SQL-injection attacks.
You also get the side benefit of having more responsive queries (you don't have to keep sending the query and redoing the planning phase each time).
The MySQL Customer Support Center retired on February 11, 2011 and migration to My My Oracle Support is now complete. As a result, the MySQL Customer Support Center is in read-only mode.
Access the My Oracle Support Welcome Center for migration information, training, significant changes and answers to Frequently Asked Questions.
Ok, so we recognise that storing plain passwords is bad or even passwords that have been simply hashed - which are vulnerable to attack.
There are various layers of defence available, such as hashing with passwords with a 'salt' (yes, my comment was generic and doesn't represent the exact recipe we use on any specific system) but better solutions exist - for example maintaining the authentication on separate back-end systems accessed via RADIUS or LDAP.
Personally, I think that the time for static passwords has passed... how many people use the same password on multiple systems? How many people never change passwords? Answer: the great majority of people. Why? Because we're innately lazy! ... and we think security is someone else's problem.
[BTW: how many of the people reading this post have an insecure front door on their house, flat or property?... Brute forcing that old Yale lock is very easy these days... http://en.wikipedia.org/wiki/Lock_bumping or YouTube 'lock bumping'. You won't get in to my castle trying that technique either... ]
The days of the "fixed password" have to be numbered? We need something better and while RSA's Secure-ID looks to have just had a significant compromise of its own recently one-time-passwords (OTPs) have to the the future...
We've just built our own implementation of RFC4226 HOTP and are evaluating it for a client project as the majority of users have Crackberry, Droid or iJobs smartphones and can run a software implementation of OTP so we don't even need a token. For those users that do need a token they can be purchased from China for $8 USD each these days :) Who needs RSA Secure-ID anyway?
Mike
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
