If I salt and hash the password, is it safer than just hashing the password if a potential attacker has the salt string and is attacking only one account - let's say there are no other accounts in the DB?
Brute-forcing and dictionary attacks would take the same amount of time, but having a salt would still prevent rainbow-table attacks.
So yes, even if your application is expected to have one user, I would still recommend a salt.
Yes, hashing passwords without salt is less safe.
Salt prevents the use of pre-computed reverse lookup tables.
Just because there is only one account in your database doesn't mean an attacker can't use a pre-computed table he generated to attack other systems. There are also tables available online for poorly designed systems like the old Windows LAN Manager.
Using salt is easy and safe. What reason would you have to skip it?
Salting helps prevent attackers from using brute force or rainbow tables to find hashed common passwords.
if the attackers knows the salt you used, you loose all protection from the brute force but will still have protection from the rainbow tables. Well unless the rainbow table was generated with your salt.
Best security is to use custom salt for each hashed password. Protects against rainbow tables and makes it a bit more annoying for brute force attacks.
Related
I'm using owncloud as my personal cloud storage, at home.
I read "Brute force attacks on passwords are guaranteed to succeed" from Brute Force Attack[Wikipedia].
Is it true? Any one who can brute force attack, can access my data on owncloud server?
I mean the login password on mobile or webserver page.
Thank you
A brute force attack will always succeed. But depending on your password it may take thousands or millions of years.
A brute force attack just tries every possible combination of password and hopes to guess the correct one. You may reduce the risk of the attacker guessing your password by using a long, complex one. Also you might be able to configure owncloud in such a way that it makes the brute force attack even more difficult. For example, let the user wait 10 minutes after 3 failed login attempts.
Yes. The key is that brute force attacks take a LONG time on well chosen and a properly stored password. It should take years.
Online services generally throttle the number of attempts allowed per minute to make this sort of attack impractical.
Badly chosen passwords and/or poor storage mechanisms may reduce the effectiveness of such limits.
This is one reason for changing you password on some interval. If the password storage were compromised and a brute force attack (or more likely one of several more efficient methods) to determine you password were underway, changing your password resets the clock.
an update:
Currently an option to "prevent" brute force attacks has been added to the backlog (as an app) in March 2017: https://github.com/owncloud/core/issues/27507
Until then, options like fail2ban can be implemented manually. Here's one of the many how-tos: https://blog.monotok.org/prevent-brute-force-attacks-against-owncloud/
The whole issue hast been discussed in the past by the developers through github: https://github.com/owncloud/core/issues/1580
Cheers!
I am making a web application when users login inserting their username and password in a form. I have been reading about brute force attacks and brute force attacks prevention, but it seems there is not an optimal solution the prevent them.
Locking accounts after some wrong attempt could enable a person (a badboy) to freeze another person's account for a X time.
Using captchas after Y failed attemps is not also a good solution, because is easy to bypass them.
Adding a delay could slow a single-threaded attack, but not multi-threaded attack(the attacker sends multiple simultaneous authentication requests).
But then I say, sites like facebook, twitter, gmail are not hacked using brute force so easily. So I wonder how the do to prevent it.
I would like to know your opinions and advices (based on experience) about how to prevent this kind of attacks?
Ya, ya. Tell us your threat model first, buddy. Are you trying to prevent brute force by someone with unlimited funds, hardware, and IP addresses? And lemme guess, you only have a AWS Micro instance...
It is not easy to defeat CAPTCHA, especially ReCAPTCHA, and it still requires work/time by the attacker. By definition ReCAPTCHA cannot be OCR'd.
If you don't like CAPTCHA, require Proof of Work. Make the user agent calculate the prime factors of a real big number. Sure, they could use thousands of computers, but that costs a lot of money.
Use a slow hash algorithm on fast servers. BCrypt with a factor of 12 is nice and slow, and you can always increase that, and run it on your own GPUs. Make sure you use a random salt, so that the attacker can't pre-calculate hashes of common passwords.
Encourage your users to use long, complex passwords.
let's just assume a simple non salted hash function, just a plain old $hash = md5($pass).
Premises:
the password hashing all takes place server side, and the hashes are stored in the database. The client has no way to see these.
a rainbow table attack must have knowledge of the hashes in order to retrieve passwords.
Given premise 2., that would mean that the hacker already has control of the database, in which point you have a much bigger problem on your hand.
So, is the point of trying to foil a rainbow table attack simply to protect the retrieval of passwords from an already compromised database/system. Is it that simple or is there something else that I am missing.
I'm already familiar with password hashing techniques, but am just wondering why there is so much hype about rainbow tables. Thanks!
Yes.
Many people use the same password for everything. Compromising the original password (as opposed to simply changing it to something you know) can often give an attacker access to someone's accounts on other services.
Rainbow tables are also much less computationally intensive (simple lookup) than a dictionary attack (which requires hashing) or brute force (which requires a lot more hashing).
Use strong, unique passwords!
Password compromise doesn't require control of the database. What if I break into your car and steal a stack of DVDs with database dumps? You do back up your database, right?
As mentioned, people use the same password for multiple sites. HBGary fell victim to this when they were hacked by Anonymous recently. One server with an SQL injection vulnerability turned into a much larger compromise.
If I have access to your database for five minutes and get the hash, I now have access to your account until you change the password.
Salt is cheap.
You should use a key derivation function anyway, not a salt.
Most of the time, data-theft from databases succeed through injection; sometimes even blind injection.
An attacker who has found a database injection exploit in one of your scripts doesn't gather any control over the rest of the system until he is able to retrieve some kind of higher credential - which could be the admin's password.
If you (being the admin) have your password stored as a simple md5() hash together with the rest of the users, and the attacker manages to retrieve it - he could eventually overtake your system by using a rainbow table to look it up.
If I understand them correctly, rainbow tables remove the computational burden of calculating the hashes (which is deliberately high), so attacking is faster.
I'm trying to figure out if it is alright to store passwords that are encrypted using the AES algorithm rather than storing passwords that are salted and hashed with SHA1.
The reason I am wondering this is because my company is in the middle of updating our membership system which is included with our proprietary CMS. Currently, we use AES encryption for passwords. This allows us to easily look up Admin passwords when customers call in for support. When we have staff changes, it is policy to change all admin passwords. The password lookup tool allows us to get the new passwords easily and our work flow isn't interupted.
I get the impression that most people think that hashing salted passwords is the more secure way of handling passwords but I can't figure out a way to comply with current company operations when using hashed passwords. And, the corporate cultural shift required to change our password operations probably won't happen unless I can give them some very compelling reasons to hash passwords.
Is a hashed password generally accepted as required versus an encrypted password? Why?
Encrypting passwords with a reversible encryption is of dubious value.
Obviously the lookup program has access to the key. That means you should assume that anyone who has access to the program also has access to the key. If you are paranoid you should also assume that their spouses, significant others, roomates, etc all have access to that key. Also anyone who has ever broken into the network ever in the past (since key was used) also has access to the key.
The problem with using a system like that is you will never know it is broken. Do I have access to the key? Right now? Can I lookup the password at anytime? As soon as you change it I know what it was changed to?
Using salted hash (vs reversible encyrption) presents its own challenges in implementation but you can be assured that stealing the password list is of little value (if properly implemented with a strong algorithm, multiple rounds, min password standards, and random per record salt). Your current system is "feel good encryption". While it may makes management "feel" safe they aren't actually being safe. It is marginally better than storing passwords in plaintext or on a sticky note it is at best a minimal speed bump to a determined attacker. The largest problem is you can never prove you are "safe" and may not have any warning when you are compromised. You could be compromised right now and not know it.
You mean, inside an application which stores passwords for user authentication.
Normally the motivation for hashing them vs storing encrypted is that it prevents someone who has stolen the database or compromised the server from obtaining the passwords.
If you encrypt them with AES, you're clearly going to have to keep the key somewhere, and can't ever change it (unless of course, you decrypt them all and re-encrypt).
If someone compromises the machine, they can obtain the key, as it is necessarily kept (at least) in memory at some time to decrypt the passwords.
It's either that, or use some fancy PKI. AES is a symmetric cipher.
Encrypting the passwords won't really help the application defend its database against any but the most casual attackers (as an attacker MUST be able to obtain the key). Hashing them makes it difficult for the cleartext to be obtained if passwords are strong.
If a hacker has access to the hashes in my DB, he has access to the rest of the information in the DB anyways. So why would he bother trying to decrypt the passwords? Should I be storing the passwords on a different server to the rest of my data? That is the only scenario in which I can envision it being useful.
Sometimes a hacker doesn't get full access to your DB. Sometimes they find a little SQL injection hole or other weakness that someone didn't code correctly, and so they can only do simple things at first like print out database cells one at a time. If they can print out a real password all of a sudden things get much worse.
Things happen: backup tapes are lost, accidentally thrown away, or stolen. A retired system wasn't wiped properly. A breach elsewhere leads to accidental exposure of a database. If a hacker gets access to a snapshot like this he can learn a lot about your system. But if the passwords are still hashed he can't also use the system to do something malicious, like log in as a different user and start changing things.
I've heard that most hacks are an inside job. Better to remove the ability even for people you trust to log in as others.
It's not about just you. Users tend to share passwords across systems. Maybe some day (God forbid) you have a breach that has nothing to do with passwords, but in the course of that breach your authentication tables will be one of the attacker's targets. If you store passwords in plain-text, you have also just compromised user accounts at many other services, and your very bad day just got quite a lot worse.
If you think this kind of thing doesn't happen, go talk to the guys at reddit.
People often use the same username/password for different accounts on other websites (including, e.g., online access to bank accounts).
Once you've discovered this hack and have secured your database, the hacker will still have the ability to login to your user's accounts.
Best security practices suggest:
You should use a unique (userId, password) pair for each account you have. But most people use a single pair for many resources (email, bank, etc). An attacker can steal them from one resource and use them to access another. Hashing the passwords with salt—see http://en.wikipedia.org/wiki/Salt_(cryptography)—prevents this sort of attack.
You should encrypt all sensitive data in your database, not just passwords. Your point that someone might steal your entire DB (or your server) is perfectly valid.
You should separate your web server from your database and any other precious resources, to quarantine an attack to your least valuable asset.
There are business reasons to hash passwords, as well. Remember, hashing means you do not store your users' passwords anywhere on your equipment.
Depending on the laws that apply, you may be required to do this in certain situations.
You greatly reduce your exposure if your data is stolen.
You're safer from social engineering attacks, in which an attacker impersonates a valid user and cajoles an employee into revealing a password. See http://en.wikipedia.org/wiki/Social_engineering_(security).
Should I be storing the passwords on a
different server to the rest of my
data?
This adds complexity to your system, but if it's something you can do it's definitely an improvement.
Note that using authentication servers such as Kerberos, RADIUS, or Windows domain authentication effectively put you passwords on another server.
Because even if you have access to the data, having access to the APPLICATION is actually more important. The Application makes it much easier to manipulate the data, for example.
Hashing the password prevents casual exposure from all eyes.
For example, you may well have the same password across several sites. A quick glance at the DB not only compromises your application, but perhaps several others.
It's just a good, solid practice to hash you passwords.
Mainly because it's nearly trivial to do it well, and the benefits can be very high.
Sometime, you don't know who will be the system administrator. You still want to protect your users from them.. So, by hashing passwords and all important information (such as credit card), you make it really harder for the hacker or administrator. And, I think password should never be written literally. I mean, I used a password since 2 years and I have never seen it written down.. why an administrator that I don't know should see MY password ?!
Using a hashed password prevents the attacker from being able to log into your app even if they know the hash. Your login page asks for the original password, so to log in using it, they'd have to reverse the hash (compute a collision). Using a rainbow table, that's fairly trivial for MD5, for example, which is where salting comes in. Then the attacker needs to know 1) the way you combine the salt and the password (not much security there), 2) the salt (which is likely in the db already) and 3) they have to compute that value for each combination of password and salt. That's a lot more than just computing hashes of common passwords and looking for a match.
When a hacker access your database it does not mean that he can access the procedural code, those procedures can alter databases outside the hacked database boundaries or inclusive can alter other procedures.
By the way now I´m going to ask you something: If a user is hacked and someone has his or her password, how do you make clear that it is not your application or security fault?
If you don't have stored passwords you don't have such responsability!
If an application is to show grade information at the university then having access to the password will allow you to get the grades for that person. If the password also allows you to log into the online course system then you can submit tests as that user.
If the data is even more sensitive, such as credit card numbers or health records, you are open to lawsuits.
Odds are that the more sensitive information may be on a more secured system, behind stronger firewalls, so they may have found a weakness by hacking into the authentication database.
By hashing the password, then those that have access to the authentication database can't see the password and so log into the very sensitive system as a different user.
The whole LinkedIn "scandal" was all about leaked hashed passwords.
As I see it, security isn't about anything other than making data retrieval inconvenient.
And by inconvenient in the ideal case we mean it'll take you millions of compute years to access (ie single CPU trying to guess at password would take on the scale of millions of years).
If you store passwords in cleartext, that takes a total of 0 compute years to access. The LinkedIn scandal would have looked much worse. All you have to do is SELECT * FROM USERS (either via injection or an insider).
People often reuse passwords, so if people learn your password, it means a whole world of data becomes accessible to them (not just their LinkedIn, for example). So it becomes a very personal risk. As a webmaster it's rude not to at least hash passwords: you don't have that much respect for your users to take the basic step of trying to protect their information.
Even if the hashed password can be cracked, you're at least taking the bare minimum step to protect your users.
If he can decrypt the passwords, he can probably get access to your user's accounts on other sites as well (as, no matter how many times we tell people not to re-use passwords, they do). Storing plaintext passwords is a good way to give away all your users' PayPal, eBay & Amazon accounts.