Algorithm against Brute-force

Asked

Viewed 1,117 times

30

I’ve been thinking about an algorithm against attacks like Brute-force which, as we have seen in case of iCloud, can generate great headaches if treated with indifference.

Initially I thought of this flow:

Login attempt:

[define uma session "tentativas" para o usuário (caso ainda não exista)] ↓

[incrementa o valor da session em 1] ↓

[faz a verificação no banco] ↓

[login correto: efetua login] - [login errado: volta à pagina de login] ↓

[verifica o número de tentativas da session] ↓

[ >= 5: bloqueia tela de login por 1 min] - [ < 5: Deixa tentar denovo]

A session-only check would be enough? Or would it be worth adding cookies, or some other checking method?

algorithm security-guard
  • 1

    good question +1

  • 1

    if I’m going to try brute force, nothing prevents me from adding a command to the script to clear the session at each attempt...

  • 1

    The idea is good and websites like Internet Banking systems do it; however, you cannot do sessions for non-authenticated users. You can, however, store in a table the number of attempts to access each distinct IP in the last five minutes. More than five unsuccessful attempts = block.

  • @Rodrigoborth the session can be server-side. If something like this is on the client’s side, then the site deserves to be hacked anyway.

  • One more thing: I don’t believe Fappening happened due to a blunt-force attack. It looks more like something you get with social engineering or stolen bank + rainbow table.

  • @Renan server side session control uses what to save records? is not an ID that gets stored in the browser?

  • @Rodrigoborth uses RAM, just... At the time the user scrolls down, or if a certain amount of time becomes inactive, the entire session is deleted. Examples of this type of session treatment are the class Httpsessionstate of the . NET and the interface Httpsession java.

  • @Renan no cara, when you create a SESSION on the server, it by default add a cookie (client-side) to manage whose SESSION is, there is SESSION cookieless that is managed by SQL, but anyway.

  • 1

    @Paulohdsousa well remembered. My fault.

  • That’s what I was referring to, I can freely delete the cookie when I feel like it from my browser... that is, there are few alternatives left, cookieless is a good, depending on how will be treated identification on the server

  • Incrementing the login screen lock time if you exceed the number of attempts can be interesting as well. Something like 2 n... Where n is the number of attempts. This makes the attack unfeasible.

  • 2

    Man, I believe the safest way is to block by IP and put a captcha on the page... The only way the guy can request with different Ips is to change it with each request or change the machine, which for attacks to sites not so big is kind of unimaginable.

Show 7 more comments

6 answers

21


The answer of the utluiz gives a good overview, besides calling attention to an important point: if your "security" is less, you are the target of a brute force attack; if it is too much, you are the target of a Dos attack.

How to solve this, I will not risk the opinion, because I am also no expert in security. But if your goal is simply to prevent a single user [arbitrary, of course] be hacked (i.e. someone tries to log in several times with the same username and different passwords), a workable solution is to progressively increase the "cost" of logging in with that user:

  • With each unsuccessful login attempt, increase the time interval needed to try again with that user (regardless whence come this login).
  • If the number passes a certain limit (say, 3) ask a captcha along with the login.
  • If it increases further, send an email alerting the fact user (but not necessarily blocking it).
  • If the number is excessive (and then I won’t risk saying what would be excessive) then block that user account.

You can do the same by IP address, to make the simplest attacks a little difficult, but as already said this is best done outside the application layer. And anyway, a measure like this is more likely to negatively affect a legitimate user (e.g.: forgot my password, but remember that it is one of the A, B, C and D) than an invader (who already expects this type of security measure and takes proactive actions to avoid them).

P.S. Complementing, remember that a hash of passwords well done also helps protect against attacks of brute force, and that a two-factor authentication is an even better way to guarantee against the theft of passwords (which in general are weak, making it a huge challenge to protect them no matter the method chosen).

  • 2

    Two-factor authentication is good, but our users aren’t ready for something this advanced yet

20

Warning: I’m not an expert on security or this kind of attack.

Cookies and Session do not resolve

Cookies and Session nay are suitable places to place this type of security.

Cookies are the customer’s responsibility (usually the browser), therefore easily manipulated.

The User Session, despite staying on the server, is just a data structure associated with an identifier, which usually stays in a Cookie or else in the URL through the URL Rewriting.

In the above two cases, requests to perform a brute force attack simply need to simulate a new user at each request, as if someone had just opened the browser, causing the server to automatically generate a new session.

Security is not only of the application

Attacks involving massive network use like this or Dos (Denial of Service) are usually best handled by Firewalls or Proxies that filter excess requests.

Leaving this in charge of the application will bring a complexity to it and will make the team spend time implementing something that is not part of the scope of the system. This distraction almost always comes at the cost of a system with less quality.

And the IP?

A simple but naive technique would be to limit the number of requests using the IP address.

This works in a simple attack, from only one source. However, more sophisticated distributed attacks will control multiple sources and it ends up being very difficult to differentiate between a "normal" and an automated request.

How to detect attacks?

Speaking of differentiate, that’s the whole question. How to detect the request pattern artificial generated by request attacks genuine originated by users?

The answer to this question makes it possible to effectively avoid brute force attacks.

I will not try to answer that here, as it will be the subject of debate by security experts.

I can even think of small techniques to make it difficult for a hacker to act, but ultimately, it will always be possible for him to identify these techniques and adjust the attack.

Maybe use a captcha or equivalent "human testing" is one of the most effective ways today, but often hinders usability and there are also guarantees that an automated algorithm that solves these challenges cannot be implemented.

Considerations

The purpose of this response is to inform web application developers not to try to reinvent security using "naive" techniques. At the same time, I want to say that security must be a concern, but requires further study, appropriate tools and expert consultation.

  • 3

    Human testing is horrible for users, but unfortunately the best way the application has to protect itself...

  • 1

    I am not an expert on the subject, but I believe that distributed attacks have in common the size of the package in the request... I think with this it is possible to identify an attack and temporarily block requests of x bytes

  • 2

    @Rodrigoborth The package size is good, but if I was a hacker, you just gave me an idea. I can create a small base if header variation, varying for example the user agent and other minor details of the protocol that do not affect the main objective.

  • 1

    @And anyway, security by obscurantism does not work by itself (help, but should not depend on it). Assume a Cracker knows everything about your system, including how to detect whether a package is legitimate or not.

5

Verification using only the session is, in my opinion, insufficient!

I recommend blocking the account after a certain number of attempts, and proceed with sending an email with a temporary password (maximum 12 hours) for the password exchange "forgotten".

DO NOT RECOMMEND THE USE OF COOKIE FOR SECURITY VALIDATIONS!

It’s very easy to change the cookie data given to some tools I’ve tried before.

Recommended reading, at least to start: http://en.wikipedia.org/wiki/Session_hijacking

  • 1

    Although I do not agree with the proposed solution, +1 by indicating the material on Session Hijacking (is everyone responding to the part that talks about the process, but hardly anyone touched on the part of the use of sessions).

  • After seeing your comment for Trxplz0, I could see that in fact it is a very aggressive and boring solution.

  • 1

    @Coldhack in fact your answer beyond aggressive to the user the COOKIE can and be used, but only to contain Session_id... because the session is an effective mechanism and if well implemented... SAFE.

  • @chambelix In reality, it is possible to guarantee almost all the security of the session data, if signing and optionally encrypting this data (what cannot be guaranteed is that they are up to date). In applications where this is not important, storing the session data in the cookie has the potential to greatly improve the performance of the application/site - by not requiring a hit in the database every request.

  • I find it an interesting subject for a new POST... but @mgibsonbr does not agree at all in storing data in a cookie. the speaking potential can easily be obtained for example with cache servers which is one of the applications with sessions carried out in production. rule number one never trust the data from the customer.

  • @chambelix If you have digitally signed the data before sending it to the customer, you will either receive the same data back or you will receive something invalid. You don’t have to trust anything! The only thing though (and in some cases this can be a problem) is that you can’t tell if the data is "fresh". Ex.: I give the value A1 in the cookie, then I A2, and then the A3. If the customer sends it back B, i reject (because the signature is invalid), but if he sends A1 or A2 I have no way of knowing A3 ever existed - not without saving session data in the BD. For that, cookie does not serve.

  • It would be interesting to analyze a secure system using cookies, because I myself have had the pleasure/need to tamper with some systems that use cookies (An example that comes to mind, without using my own tools was a system that saved in cookie the amount of attempts). For another @chambelix, cookie store session_id for what purpose? Wouldn’t that give the possibility to change and perhaps "simulate someone’s session"? Interesting...

  • @mgibsonbr "signed" data in a cookie is an alternative but limiting and as I said there are other alternatives... it depends perhaps on the type of information... for example... for me is not an alternative to consider.

  • @Coldhack thought that otherwise in most cases the only data stored in a cookie was session_id or am I wrong? when you say "cookie store session_id for what purpose?" is that what you mean??

  • Illustrious @chambelix, my question is meso this, to know the utility/need or how the web browser uses the session_id stored in the cookie? I was able to search and saw that yes, there is the cookies Session that essentially stores the session_id, but it awakened in me the possibility of capturing someone’s session ID and changing mine and... The link I post I believe expands this idea better (Session sidejacking).

  • Illustrious @Coldhack... in Session Hijacking the beginning goes by obtaining the session_id, and then a cookie in SSL is one of the ways to solve, in other words a site that uses SSL is safe against "sideJacking" but this removes us from the main issue that started this conversation. or the basic algorithm.

  • Exactly... that would be outside the scope of this issue in fact! However, a site that uses SSL is "safe" and not secure(totally). I believe that in another forum could give some light to why a site with SSL this "safe", because losing a little time is possible. thanks for the contribution... at the end of the day, my solution is really aggressive :D

Show 7 more comments

5

I have read all the answers and I agree with all of them. However I would like to introduce the theme of server responsiveness or server pool.

But before and looking at the question I want to add that, in my opinion, a system should be able and without harming real users to the detriment of the alleged "hackers" implement an authentication policy that does not block. However, what if you do... put an arsenal of tools in place to resolve the situation you surely did not create. Unsatisfied user is a user who does not want to use the service.

Therefore and in my opinion the user first.

Then, following my first paragraph... Say that before the given algorithm the number of attempts will have to be saved, but possibly only after checking in the database the total number of attempts before incrementing.

Both the recording of this increment and the validation of it must be well targeted, as it is a database as indicated and a "brutal force" attack the calls will succeedif and certainly the blocking of nothing will solve because the service can be clogged with so many accesses that despite the effort of implementation of the counter this will never be effective.

Therefore, credential authentication security will not be restricted to this question alone. In the @utluiz answer the phrase:

Security is not only of the application

makes perfect sense and if possible see the whole picture.

To finish by saying as an example that I have been involved in a project of an "identity manager" and I can say that the service contains more than one HTTP server after these access the cluster to validate credentials next to the data pool.

Until I get here many are the security processes used, however and for me one of the best is this separation, where puts me the possibility of defining in the database servers the IP’s of the HTTP servers that can access, without allowing any other access.

And yet good monitoring is required.

4

Warning: I’m not an expert on security or this kind of attack

Mode 1

One mode that I use and that you can use is to block the LOGIN/EMAIL after you have missed the password 5 times.

LOGIN/EMAIL is only unlocked after changing the password ( sends a link to the registered email p/ it enter a new password )

A problem with this technique is that it makes it possible to block someone else’s accounts - thank you @Daniel Omine

Mode 2

Utilizar Captcha

  • 5

    Changing the password is a major inconvenience for most users (unless they already use password managers, not having to memorize them). This type of measurement would probably cause users to choose weaker passwords (e.g., a prefix, with a suffix that increments with each "password change"), or annotate them somewhere, etc. I remember someone (I think it was Schneier) who said: "security only works if it’s easy"...

  • 2

    It may be an inconvenience, but I assume he’d rather lose 1 minute resetting the password than go online.

  • 1

    1 minute to think of a new password, sufficiently different from the previous one, to memorize it, and to remember that that password belongs to that service (among the thousands that it accesses)? I don’t think so...

  • That may be, but at least in my humble opinion, it’s a quick and easy way, I don’t think it’s the best.

  • 4

    My "user" side hates forced password exchanges. "Worse" even when the password policy does not fit my set of "default passwords". Yes, I have a set of passwords that I use on different sites, according to the "category" of the same. Obviously, the most important sites get "better passwords".

  • 6

    A problem with this technique is that it makes it possible to block someone else’s accounts. For example, I create a bot with quite obvious names and trigger 6 attempts of purposefully wrong logins. That’s enough to block all these accounts. I can create a package with 10, 200, 50 thousand, 10 million accounts. Do you understand the huge problem it becomes? Imagine thousands or millions of users with their accounts blocked.

  • 1

    @Daniel Omine never thought about it, lucky that the system that used it is an internal system :), but it is really a serious flaw.

  • I would not recommend this form of specie any, since some user can try to harm another user infinitely in this way, always blocking his password. I’ve always found the systems that implement this kind of technique to be extremely flawed. I have worked in a Call Center that used this technique, had users chased by users from other Call Centers and could not login more, because the login of everyone was in the system.

Show 3 more comments

3

Of course, none of the techniques already mentioned solves the problem completely. With what we have available, we can do as many have said here:

  • Missed password more than 3 times, uses Session and prompts a captcha.
  • Missed the password more than 2 times, hitting the captcha, blocks the ip for 2 minutes.
  • If the second IP lock occurs, lock the account and request unlock!

There are people confusing with Ddos attack that aims to reach the source, stopping your application and all others who share the same server, IE, no one will access anything, including you!

  • 2

    People have mistaken Ddos for what?

  • 1

    No one is confusing it, is that the requirements of authenticity and availability are opposites: make it very easy to authenticate, and someone will impersonate you; make it very difficult, and someone will block your access (by trying to impersonate you, fail, and block your account). That is, it is a type of denial of service (Dos) yes, not necessarily distributed (Ddos).

  • 2

    Exact @mgibsonbr, so I had not noticed the issue of confusing "Ddos". On the other hand, now I can see that easily blocking accounts may not be the best thing, because it gets boring every day having to activate my account again, when it’s another person trying to access by brute force attack.

  • @Coldhack Hehe is that I was commenting for the author of the reply, but you posted a similar comment at the same time that I... P

  • In case he wants to block this is the solution. There will always be someone trying to circumvent mainly if their service or application is something public with a lot of access, as well as the troll user blocking other people’s account, Brute Force is not Ddos. It is up to you to define the access times and the number of attempts.

Browser other questions tagged algorithm security-guard

You are not signed in. Login or sign up in order to post.