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!
Related
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.
In light of the recent data breach at Blizzard I want to ask about brute-force and salted-hash password storage.
Ars Technica has a good article on why even the salted-hash passwords that Blizzard stores can be cracked in short order.
Because of the salting and hashing used, we know that a brute force attack is the only viable way to crack the "complicated" passwords (dictionary/plain-word passwords are trivial)... However Ars Technica makes a good point that the vast improvement in computational power (both local and in the cloud) makes brute-force cracking more viable.
For a website, Jeff Atwood notes that forcing delays in authentication attempts can realistically thwart brute-force attempts.... But in the case of the Blizzard breach, hackers have physical control of the DB, so no such accessibility limit can be imposed.
Consequently, Jeff also recommends pass-phrases because of the increased entropy facing a brute-force attacker.... But this, too, will eventually effectually fade as computational power becomes greater and more accessible.
So the question is: What brute-force protection schemes can be implemented that aren't vulnerable due to increasing computation power?
Two-stage authentication is often considered, but I've heard that some of these algorithms are also being broken, and a physical authenticator has a likely static algorithm, so once it's cracked all users would be vulnerable.
What about scheduled rolling salts that apply to the entire authentication DB? This would add a lot of overhead but seems like it would secure even in cases where the physical DB is leaked.
Security is a combination of a few things (there is much more than this list, but rather than turning this post into a book, I'll keep it at these for now):
Encryption - complexity; making it difficult to know what the original content is
Obfuscation - unclear/protected; making it difficult for other scripts/users to know or guess how your security scheme works.
Intrusion Prevention/Response - determining when a security breach (or attempted breach) has occurred, and responding to the incident
Encryption will be things like hashing, salts, SSL, keys, etc. Obfuscation will be things like steganography, using rotating salts, separating the passwords off into another server that no script can access, etc. Intrusion Prevention/Response will be things like rate limiting, delays, shutting down servers once the breach is made known, etc.
Now looking at your question: What brute-force protection schemes can be implemented that aren't vulnerable due to increasing computation power?
My answer: none. Unless someone builds a quantum computer or a mathematician writes an expansion to group theory in a way that would blow all of our minds out of our heads, then any and all "brute-force protection schemes" will be vulnerable to increasing computational power (especially distributed processing, such as cloud servers or bot-nets).
It seems like your fear is the case of Blizzard, where the database had been accessed, and the hashed passwords were seen by the hackers. If someone has the hash, and knows your salts/hashing procedure, then it's only a matter of time before they can get the password. At this point, we are talking only about encryption, because everything else is known and/or moot.
It's a matter of math: the longer and more complicated the password, that's increasing orders of magnitude, and the problem becomes an exponential with each added character. But if you exponentially increase the computational power of the brute-force algorithm, you're back to square one.
If a hacker gets a hold of the hashes that are stored in your database, then immediately lock the database, figure out how they got in, fix that security hole, and add a step to your authentication procedure, update the database with the new authentication procedure and turn everything back on.
In other words, make sure your authentication server/database is secure on every level so that hackers can't get access to it.
If you just want to "buy more time", then add complexity. But keep in mind that this doesn't make your database more secure. It would be better to analyze how to lock the database down to prevent someone from getting the hashes in the first place.
I want to put a measure in place to stop people from trying to hack user accounts on my website. What would be the best process behind this without being annoying to a customer who just needs to try a few passwords to remember?
I notice Google shows up a captcha image after a couple of failed attempts. I've never tried hard enough but I'm sure they must block you after quite a few attempts.
Would would be the best practice to ensure that someone doesn't try a brute force approach to gain access to an account?
captcha ?
Blocking their IP Address (does this work if they're on a shared IP)?
Your best bet is to lock out(10min, 15min, etc...) on a per-username basis with a relatively high number of tries possible(10 or 20 or so) in a set period(e.g. rolling 30min window). By setting the number of tries higher than 3 or 5, the average user will either give up or attempt to reset their password before the lockout hits.
You may consider logging failed attempt data(IP, username, timestamps, ...) to understand behavior differences between normal user behavior and brute force attempts. This will allow you to refine your policy over time.
Also consider a strong password policy(at minimum 8+ characters with at least one number).
You may also consider some form of multi-factor authentication. You mentioned captcha but there are many other techniques you may find useful. One site I work with will email a token to a user's email address if they do not recognize a user's IP address and the user must present that token before they are able to access from the new IP address.
Schemes that lock a user out after a certain number of attempts and/or extend the time that it takes after further login attempts are accepted again are certainly a good idea. As are CAPTCHAs (aside from being annoying :) But, in my opinion, they only make sense if you have strong hardware backing you.
The reason why I believe this should only be tried if you have the resources to do so is that you have to keep in mind that a scheme like that requires you to remember the attempts recently made for potentially every user in your system. Certainly, there are numerous ways of persisting the information, varying in their effectiveness: in-memory cache, database, etc.
But no matter what, such a mechanism will put additional load on your application, and there's the downside: if an attacker gets bored or annoyed by your app, they might as well try to take it down with a denial of service attack. And complicated login schemes that need to persist a lot of information will help a lot in achieving that goal.
If you decide to apply such a feature, I would recommend you stress test it a lot in a lab first to get a feeling for "how much you can take" - this way you'll find out if you need to upgrade your hardware :)
An easier way that can do without the need for persistence is to apply a password hash like PBKDF2, bcrypt or scrypt. These artificially slow attackers down enough to make it as hard as possible for them. But be aware, that these, too, put additional computational strain on your application (although presumably less than the aforementioned measures), so again I would do some stress tests first.
If my website uses a POST form for login, what is a quick and easy way to prevent a rogue client from flooding my web server with POST requests trying to brute force crack my user accounts?
PHP/MySQL/Apache.
Preventing brute force cracking is trickier than it may at first seem. The solution will be to combine controls - one single control will not cut the mustard. And remember the goal: you want to slow down a brute force attack to the point where it will either be ineffective, or you can detect it and take action. The second option is generally more effective than than first.
You could use a captcha (this is currently a popular technique) but captchas can often be automatically read, and when they can't be read by a computer, farms of people can be be obtained by paying low waged workers or by using the captcha to protect "free" porn (both techniques have been used).
The advice of others to use a secret value in the form won't really help; an attacker simply has to parse the HTML to find the secret value, and include it in their post. This is pretty simple to automate, so it's not really a good defense. Oh, and if the value turns out to be easily predictable (using a poor or broken PRNG or a bad seed) you're up the creek, again.
Tracking the IP address is okay, but only if you don't support NAT. With NAT, valid users will appear to be duplicates. And remember that attackers can impersonate other systems; a single attack system can use other IP addresses, and even intercept the traffic to that system (ARP poisoning is one good mechanism for this).
You could use a max number of failed timeouts in a given period of time (like 3 within 1 hour). This slows the attacker down, but doesn't necessarily stop them. You might include an automated unlock, but you'll need to do some math, and make sure that the unlock time is actually useful.
Exponential backoff is another useful mechanism. This might be possible to tie to a session (which the attacker doesn't have to return to the server) to the IP address (With breaks with NAT) or to the account (which doesn't account for brute forcing across multiple accounts).
For the other defenses to be useful, you have to have strong passwords. If your passwords are easy to guess (are they in a dictionary? are they short? are they complex?) the attack will succeed. It's a good idea to implement minimum password strength requirements, and an "illegal passwords" dictionary (combined with common character substitutions for that dictionary). Alternatively, you might use a system like OATH, certificate login, or hardware tokens (like RSA's SecurID).
I think it was Burt Kaliski who discussed client puzzles. Basically, you give the client a challenge that's easy for the server, but difficult for the client; the client DoSes itself by wasting its own resources trying to solve the puzzle. The difficulty, here, would be in determining the right complexity for the puzzle. It might, for example, be factoring a large number. Whatever it is, you'd have to assume the most efficient possible algorithm, and you'd have to be able to handle different performance of different browsers on different machines (potentially slow) while slowing down automated attacks outside of browsers (potentially faster than your javascript). Did I mention that you'd have to implement a solution in JavaScript?
But you're still stuck with an attack that works across multiple accounts. I'm not aware of any publicly used controls that work well against this, unless you can track IP addresses.
Then, you'll want to protect usernames. An attacker who doesn't know usernames (requiring a system that doesn't indicate when usernames are valid) will have to learn both the username and the password, instead of easily confirming a username, then just attacking passwords.
And you'll need to be careful that error messages, and server timing don't give away (in)valid passwords, either.
And when you deal with error messages, make sure that password recovery mechanisms don't give anything away. Even in otherwise good systems, password recovery can blow the whole thing.
But, all that said, the attack is ultimately dependant upon the server's performance. You might simply implement a very slow mechanism for authentication (has to be slow for both valid and invalid authns). An online attack is guaranteed to go no faster than the server can process requests.
Then, you need to detect brute force attacks, so your system needs a good audit trail. But you'll need to be careful not to log too many log messages or you'll open up an easy way to dos the server by filling up disk space. Something like syslog's "the previous message has been received 1000 times" message would be good.
Once you're all done designing things, and again when you're done implementing things, you'll want to examine the whole system, and all features of the system, mathematically model it given the current settings and the server's performance and determine the average amount of time it would take an attacker to brute force (a) a single account, and (b) any account (brute forcing across accounts to avoid account-specific controls).
One approach is to keep track of the IP address (or even of the first 3 octets of the IP Address) of each request and to add a significant time in responding to (or even to drop) the requests coming from IPs that have had more than x requests in the last y minutes.
This is ineffective (or less effective) against distributed attacks, but otherwise work quite well, for a relatively simple implentation.
For a stronger proptection, one can also blacklist offending IPs (IPs, or again first 3 octets of IP, which have submitted more than say 6 bad attempts in the last 2 minutes or less) by systematically denying access to such IP for a period of say 15 minutes.
Well, if you know the IP of the source of the login attempt, you could allow it 5 attempts, then make that IP wait through a 5 minute "cool-off" period. If you think 5 minutes is too short, raise it until it's something more suitable (could go as high as 24 hours, or more if you think it's necessary). This might not work as well if they have dozens of coordinated nodes in a botnet.
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.