Brute force a confirmation code?_问答_开发者_运维开发者技术经验分享

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 .ne开发者_运维技巧t programing forum where I can go with my questions.

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...

First of all, if the confirmation codes are truly random there'll be 16¹² = 281474976710656 possible codes — each one equally likely to occur. That could take quite a while to brute-force.

Anyway, if you want to show your boss how such a thing could be brute-forced, you just need a loop that'll generate all possible codes and try them one-by-one. Here's an example in C:

int code[12];
for (int i=0; i<12; i++) code[i] = 0;
while (1) {
    for (int i=11; i>=0; i--) {
        code[i]++;
        if (code[i] < 16) break;
        else code[i] = 0;
    }
    for (int i=0; i<12; i++) printf("%x", code[i]);
    printf("\n");
}

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

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
}

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

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.

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.

I know its an old question - but I just found this.

Another way of thinking about it, is even if the hacker brute forces the code, you make the 'result' that a new email is sent to the original user with a new random password - so all the hacker has achieved is resetting a password for a user, which doesnt actually help them!

So therefore the issue of combination codes, attempts at brute force - are redundant.