Didn't they say that there were a week's worth of new users and content removed? That implies that there was user data stored on the exploited server. Maybe I misread something; if I did please correct me.
As said by Dragoneer:
This attack targeted the site’s database by deleting user information, submissions, and watches. It was stopped before any further damage could be done. Other information such as journals, notes, passwords, and personal information was not affected. We're currently in the process of doing a security audit on the existing code and closing any loopholes which may be accessible from the source code.
We are also working to restore the deleted data. Our most recent full backup is from May 11, so approximately 6 days worth of new user registrations, account watches, and new submissions have been lost due to the attack. We are still trying to evaluate the scope of the attack.
Ah I see. So they are just restoring a backup from 6 days prior even though the data was not deleted. Thanks for the clarification. It is still strange how he says that user information was attacked, yet nothing important was deleted. Sounds like a strange setup they have =P
Like a little pat-down at the door? That'd be difficult, those things are so easy to disguise, there are soooooooo many novelty ones...this is actually a 2GB jump drive![]()
<3333 Someone gets it!Now you're on my time you little skunk!
Straight hashes by themselves are a stupendously bad idea. Only thing worse than storing the passwords as a simple hash is storing them in the clear. (Also bad idea: Encrypting the passwords. Because that's like storing them in the clear, but you get a false sense of security out of it.)I do development and things like this interest me, so I was just hoping one of the developers or staff members would be able to fill us in. Feels like if the exploiters had access to the database, they also had access to user passwords. Even if they were hashed, there is still the potential that they were hashed with an algorithm like sha1 or md5, which are meant to be very fast and mainly used for verification of file contents. It's not hard to put a bunch of hashes into some brute forcing software and get a few weak ones within a minute or two. So I think it would be a good idea to change your password.
Was a random, but very well loved reference. x3<3333 Someone gets it!
HahaWas a random, but very well loved reference. x3
I don't know where I was going with that to be honest.Didn't they say that there were a week's worth of new users and content removed? That implies that there was user data stored on the exploited server. Maybe I misread something; if I did please correct me.
Yay! I love cryptography.Straight hashes by themselves are a stupendously bad idea. Only thing worse than storing the passwords as a simple hash is storing them in the clear. (Also bad idea: Encrypting the passwords. Because that's like storing them in the clear, but you get a false sense of security out of it.)
The correct way of storing user passwords is with a specific password algorithm like scrypt or bcrypt which of course also mean that user passwords are stored with a salt. Which are specifically designed to be hard to parallelize, and to require longer compute times. Your next best choice is to use good ol' PBKDF2 introduced back in PKCS #5 v2.0; which is an iterative process involving an HMAC (the standard being HMAC-SHA1) iterated a huge number of times, which are increased as time goes on (Apple iOS 4 runs 10000 iterations, while server-side hashing for LastPass is 100000 iterations). A "salt" is a random number stored alongside the password in the clear, which is concatenated with the password before the password is hashed. That way you can't use a rainbow table to find hashes of common passwords (you'd need to recalculate the rainbow table for each salt).
Of course there's much better methods of login and authentication than passwords, but the average user has no idea what a public/private keypair is, or how they work.
I'm a crypto nerd, ask me anything.
Yeah I understand that just a plain old hash isn't the best way to store passwords. I was just giving an example of one without any sort of hashes. Storing passwords with just hash(salt + password) is pretty common on sites, as I've seen it used over and over again. If we're talking encryption, (which is, yes, a terrible way to store user data) then PasswordStore is really neat. You use your own public GPG key to encrypt the passwords or data and then it allows you to create a git repository to store the encrypted files (not the private key though): passwordstore.org: Pass: The Standard Unix Password ManagerStraight hashes by themselves are a stupendously bad idea. Only thing worse than storing the passwords as a simple hash is storing them in the clear. (Also bad idea: Encrypting the passwords. Because that's like storing them in the clear, but you get a false sense of security out of it.)
The correct way of storing user passwords is with a specific password algorithm like scrypt or bcrypt which of course also mean that user passwords are stored with a salt. Which are specifically designed to be hard to parallelize, and to require longer compute times. Your next best choice is to use good ol' PBKDF2 introduced back in PKCS #5 v2.0; which is an iterative process involving an HMAC (the standard being HMAC-SHA1) iterated a huge number of times, which are increased as time goes on (Apple iOS 4 runs 10000 iterations, while server-side hashing for LastPass is 100000 iterations). A "salt" is a random number stored alongside the password in the clear, which is concatenated with the password before the password is hashed. That way you can't use a rainbow table to find hashes of common passwords (you'd need to recalculate the rainbow table for each salt).
Of course there's much better methods of login and authentication than passwords, but the average user has no idea what a public/private keypair is, or how they work.
I'm a crypto nerd, ask me anything.
I predict a DDOS caused by large quantities of pr0nz.