Encryption/Decryption has a ton of overhead - so encrypting "everything" isn't always the best idea. I've worked on authentication databases getting thousands of queries per second. The standard is a seeded hash. But it's only meant to temporarily slow an attacker down.
Wow I had no idea such databases would see that kind of load.
It isn't just about logging in and logging out. Many of these databases tend to be relational databases for things like websites - and not only does access get checked on login/logout, but ALSO on page loads. Imagine if you were a member of an internet forum and got banned. That ban would likely take effect immediately, right? Not on your next login attempt So there are queries going to these databases for things like "Does this user still have this access?". Sure, there are messaging busses and a slew of other ways to get around constant SQL queries, but that tends to be how things are designed.
For most UNIX systems, they'll tend to use some kind of LDAP for authentication back-end. Not only are there queries on every login, but likely queries on almost every command the person types.. to look up a user ID of another user, etc. etc. Meta data of sorts.
So yeah, I've seen relational databases that *just* power authentication for big products handling 5000-6000 queries per second (which is actually tiny for a relational database). And then there's the LDAP servers which get slammed even more than that with "searches".
Can someone explain to me what 'salted' is?
I'm also guilty of the 1 password for many sites, got too many accounts my password list would be a mile long :'(. Although all my important stuff is on separate passwords, like bank and email so I'll probably be fine.
Basically, the "salt" is added to your password prior to hashing to add another layer of security. For instance, say your password is "password" and using a standard hashing algorithm, the token stored in your database is "1234567." If someone got a hold of your database and had a rainbow table (pre-computed lookup table) for your algo, they'd easily be able to lookup the dictionary word "password" and match it up with "1234567."
With a salt (the more complex, the better), however, "password" + salt might be hashed to "7364521," which would not be a valid hit in the rainbow table. This makes brute force/rainbow hacking much more difficult.
Hope that makes sense...
And of course, adding to this problem are the sites that require you to register to do damn near anything, or the ones that won't let you go through the checkout unless you register "for future convenience."Can someone explain to me what 'salted' is?
I'm also guilty of the 1 password for many sites, got too many accounts my password list would be a mile long :'(. Although all my important stuff is on separate passwords, like bank and email so I'll probably be fine.
Two different protections were in place. Account and email information was using normal AES type stuff . Financial information was AES + salt , with a unique salt for each account.
The chances of anyone using the credit card information is next to zero, but they had to warn users anyway. The account information is much much more likely to be compromised because it is simple AES cracking which a gpu can do very quickly.
The biggest threat is people that use the same password for lots of sites. STOP DOING THAT! .
Worst case:
You use the same password with multiple sites. They get your password, download your email, find emails to banks, ebay, paypal and more which they can now login to thanks to using the same password across the internet.
I can't stress this enough, don't use that same password on more than 1 place. I know so many people, probably 4 out of 5 that use the same password everywhere.
I wish them luck brute forcing my steam password, it is 384 bits long.
I figure a good idea would be to use something like KeePass and remember that one password and creating individual ones for each site and simply storing them inside keepass.
It's so very tempting to use the same one for each login.
Also when a site has the option for using your mobile device to get access to the account you should use it. It's a one time password and pretty secure. Nobody is going to get your cell and then try to access your bank or gmail etc.
I figure a good idea would be to use something like KeePass and remember that one password and creating individual ones for each site and simply storing them inside keepass.
It's so very tempting to use the same one for each login.
Also when a site has the option for using your mobile device to get access to the account you should use it. It's a one time password and pretty secure. Nobody is going to get your cell and then try to access your bank or gmail etc.
The one problem I could see with this is if you try to login to a site somewhere else you either won't know the password or may not remember it. This is why I take a base password and make variations on it of varying degrees of safety for various sites.
Can someone explain to me what 'salted' is?
Salting is the name given to mixing something with a password, prior to "hashing".
There is a weakness with storing hashes of passwords, which is that it is now becoming practical to build dictionaries, which you can use to match a has with it's password.
Let's take a naive approach of just storing the hash of a user's password. Let's assume user Alice sets a password of "password" and that the site uses an MD5 hash. "password" gets hashed to "5f4dcc3b5aa765d61d8327deb882cf99". The hash "5f4..." gets stored in the database.
A hacker then manages to steal the database, and they find the hashed password "5f4...". The hash value "5f4..." cannot be used to back-calculate the password. However, it is practical for an attacker with a powerful computer(s) to build a dictionary of "common" passwords over a period of weeks, months or years. Then following a hack, they can simply look the hashes up in their dictionary and see if they get any hits.
Without a hash, is that the same dictionary will work to attack any database that uses the same algorithm. This makes building dictionaries (especially sophisticated dictionaries, like "rainbow tables") an extremely economical job for hackers. They only have to build the dictionary once, and can use it over and over again.
A better security method is to "salt" the passwords. At a basic level, the site admin could think up a random string, e.g. "AHigherSecurity". In this case, the database would store the password by adding the salt. i.e. "AHigherSecuritypassword", then calculating the MD5 and storing that. (79fea0e5e53d267f8897540ebf74453f)
In this case, a hacker may be thwarted because the hash "79f..." is for a long and complex password, and is unlikely to be in an attacker's pre-calculated dictionary.
This works fine, but there is still a weakness. If the attacker finds out the salt, and the database has a lot of passwords of high value, then they could simply set out and build themselves a new dictionary with the salt taken into account. However, in this case, the attacker would have to build a new dictionary for each and every site that they attack. A pre-made dictionary won't work. They have to build it after the attack.
The preferred way to get around this is to use a different salt for each password. You then store the salt along with the hash. In this case, an attacker would be wasting their time with dictionaries, as each dictionary could only be used for 1 password. The only option is brute force and ignorance (which would require a disproportionate amount of computer resources). It doesn't matter if a hacker finds out what the salt is because all the salt is for is to stop the salt/password combo from appearing in a dictionary.
Some security experts recommend double salting. This means using a salt for each password, and a 2nd salt which is the same for all users. The individual user salts are stored in the database, but the application salt is stored in the app code itself, which means that the hacker would need to get hold of both the database and the application code in order to try extracting passwords. The double salting also makes the passwords even longer and more complex making brute force attacks even less practical.