Two or three steps above EPIC fail
oh, and the https certificate for the customer.mysql.com domain expired a month ago
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 …
oh, and the https certificate for the customer.mysql.com domain expired a month ago
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.
Oh that's good timing for them, I believe there is a lad in Iran who can do them a good deal on a new one right now.
"the director of product management at WordPress used a four digit number as his password"
Might be time for him to change his PIN and/or any door codes he uses. :)
I use the same combination on my luggage!
FACEPALM says it all
For bonus points it would be interesting to see if those 4 digits related to a day - month part of his or other halves birthday.
"This information revealed that the director of product management at WordPress used a four digit number as his password"
Said director AT MySQL used a 4-digit password FOR his (presumably locally installed) Wordpress account.
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...
For the info. Now if anyone gets password hashes from any of your clients they know what the salt will most likely be.
Enjoy your false sense of security. If the bad guys compromise the system to the extent that they gain access to the hashes, the salt won't remain "hidden" for very long.
The salt, it does nothing! Use bcrypt. codahale.com/how-to-safely-store-a-password/
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.
Of course he might be describing the general technique they use rather than giving the precise recipe you know.
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.
"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.
Isn't the whole point of cryptographic systems that such a process is near-impossible?
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!
As a IT engineer, it's not always our fault. Sometimes the damn boss refuses to adopt procedures like common sense complex, aging and minimum length passwords!
All well and good but if you insist on x$£dvEt@@756thisImypAssW0rd4321 as your passwords, then people will just write them down and post it to the monitor. Ok for a web facing server, not so good for an internal system.
As an IT security analyst, I can vouch for the truth of that.
I once had a CEO that refused to use a password to log on. He got lucky and wasn't compromised. We did finally manage to scare him into compliance and he was grateful in the end.
I fail to sympathize with any organization that fails to use prepared statements and gets hit by an SQL injection.
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).
PDO in PHP with bound params, it's actually more efficient for obvious reasons too.
Anybody vulnerable to SQL injections in this day and age really needs to start firing people.
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.
"Because the variable-values are kept separate from SQL, it's (AFAIK) immune to SQL-injection attacks."
Wouldn't you put the select statement in a stored procedure, the parameter would be on the WHERE clause.?
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?
"Access the My Oracle Support Welcome Center for migration information, training, significant changes and answers to Frequently Asked Questions."
but links for the free MySQL Community Edition take you back to www.mysql.com.
Biting the hand that feeds IT © 1998–2017