views:

88

answers:

7

I have a site and for a user to reset this account a confirmation code is email to them, however, after talking it over, it seems this could be a huge security hole. I'd like to make a small app that I can use and show my boss how unsafe the site is.

Basically, the code's length is 12 characters with the last 4 being fixed and it only uses hex characters 0-9 and a-f

So my theory is, is the hacker knows the user name he could brute force the Confirmation Code making the users password worthless.

Anyone know a good place to start on making a program like this?

I know it is a programing question with code, but I feel that it is valid to be posted. If not, please direct me to a .net programing forum where I can go with my questions.

+2  A: 

http://www.owasp.org/index.php/Blocking_Brute_Force_Attacks http://www.codeproject.com/KB/architecture/brute-force-attack.aspx http://www.xdevsoftware.com/blog/post/User-Authentication-in-ASPNET-to-Prevent-Brute-Force-Attacks.aspx

This might get you started...

Yves M.
Such a quick response! Thank you, I'm off to sleep right now, but I'll read them in the morning when I get to the office and maybe just demo someone else's program to show the security issues.
Landmine
+1 For not just using a calculator.
Gumbo
+1  A: 

That’s about 281 trillion combinations. Brute-forcing them would take long enough to not be an issue for your site.

Even if, as you say, only the first 8 characters (4 bytes) vary, this is still 4 billion combination. Assuming 100 tries per second, it would take about 16 months to brute-force. I sincerely hope that your server admins would detect such an attack in over one year.

Additional security would be introduced, as Thomas suggested, by letting the codes time out after a week or so.

Scytale
Sadly, only the first 8 are random for some reason, the last 4 are a fixed pattern.
Landmine
Updated my answer accordingly.
Scytale
+1  A: 
David
What if only the first 8 were random? 4,294,967,296 possible?
Landmine
@Landmine: Yes, assuming the rest were not only non-random but in fact fixed (or at least easily derivable from some other known data like the username itself).
David
@Landmine: Give a count, `n`, of possible values. Then average time to brute force is half the time to try every possibility. Assuming you can do `r` per seconds, then the average time, in years, is `n/(r*60*60*24*365*2)`. This works for anything. (And don't forget that multiple computers in parallel will increase `r`.)
Richard
+1  A: 

I know this is likely to not be an accepted answer, but that seems reasonably secure, with 16 possible positions per character.

16^12 = 2.81474977 × 1014
Ben Dauphinee
+1  A: 

There are 281474976710655 possible combination with the given code length. Even if it takes 1 second to attempt one code, it will take years to brute force it...

Still if you wish to try, you need to write something like:

for (Int64 i = 0; i < 281474976710655; i++) {
    string code = i.ToString ("X12");

    //write code here to attempt this code
}
Hemant
+1  A: 

With 12 characters in the range [0-9a-f], there are 281474976710656 possible confirmation codes. Assuming the hacker can do 1000 attempts per second (which is rather unlikely), it will take 281474976710 seconds to try all possibilities. This is about 8925 years... I don't think the user will care if a hacker hacks into his account in 8925 years ;)

Just to be sure, you can associate an expiration period to the confirmation code. Make it valid only for 24h, or 3 days, or whatever you want

Thomas Levesque
That's a brilliant idea, and it was suggested, however, the heads think that no action is needed until there is an event.
Landmine
Remember - given a normal distribution of codes over the available ranges, it will in fact take, on average, 4462.5 years to brute force a code.In short - there won't BE an "event" :)
Jamie
@Jamie, indeed. That's why I said "to try all possibilities", not "to brute force the code" ;)
Thomas Levesque
A: 

There are 2^32 ≈ 4 billion confirmation codes, so brute force requires an average of 2 billion attemps. If they can only be tried online, that's enough, provided that the number of confirmation codes that can be tried by an attacked is significantly smaller than 2 billion.

Note that this requires both a cap on the number of times a given confirmation code can be tried and on the total number of account resets accross all accounts. The latter could be a problem in some circumstances, for example if a news article announces (truely or falsely) that your user database has been compromised and everyone rushes to change their password.

For an attacker targetting a specific account, the thing to be aware of is that this makes anyone who can receive mail at the given address in control of the account at your site. So not only anyone who impersonates the e-mail account, but anyone who can snoop on the e-mail account can impersonate the account at your site. That's not necessarily a problem, but it should appear clearly in your security model.

Gilles