Comments on: Username Enumeration Vulnerabilities http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/ Information Security Think Tank Sat, 02 Feb 2013 17:50:40 +0000 hourly 1 http://wordpress.org/?v=3.4.1 By: Idetrorce http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/comment-page-1/#comment-86893 Idetrorce Sat, 15 Dec 2007 11:10:32 +0000 http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities#comment-86893 very interesting, but I don't agree with you Idetrorce very interesting, but I don’t agree with you
Idetrorce

]]> By: BlogSecurity » WordPress Username Enumeration http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/comment-page-1/#comment-35883 BlogSecurity » WordPress Username Enumeration Wed, 18 Jul 2007 11:39:08 +0000 http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities#comment-35883 [...] post is the follow up to my previous work on username enumeration vulnerabilities. In this post we primarily concentrated on various [...] [...] post is the follow up to my previous work on username enumeration vulnerabilities. In this post we primarily concentrated on various [...]

]]> By: Adrian Pastor http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/comment-page-1/#comment-14058 Adrian Pastor Wed, 11 Apr 2007 19:15:12 +0000 http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities#comment-14058 naka, I'm guessing that when you say handicapped people, you mean people with sight problems. In this case, I would think that applications like Windows magnifier would be more than enough to read the CAPTCHA. On the other hand, if the handicapped person was completely blind, then there would be a problem since voice synthesizers wouldn't be able to pick up the text in the CAPTCHA. Interesting point though. Regarding the importance of this vuln, it really depends on the nature application and the privilege of the username that has been enumerated. Username enumeration does nothing but help you when cracking accounts. I've historically considered this type of vulnerability almost useless, but like everything in this field, when you push the limits and get successful results you change your mind completely. naka,

I’m guessing that when you say handicapped people, you mean people with sight problems. In this case, I would think that applications like Windows magnifier would be more than enough to read the CAPTCHA.

On the other hand, if the handicapped person was completely blind, then there would be a problem since voice synthesizers wouldn’t be able to pick up the text in the CAPTCHA.

Interesting point though.

Regarding the importance of this vuln, it really depends on the nature application and the privilege of the username that has been enumerated. Username enumeration does nothing but help you when cracking accounts. I’ve historically considered this type of vulnerability almost useless, but like everything in this field, when you push the limits and get successful results you change your mind completely.

]]> By: naka http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/comment-page-1/#comment-13940 naka Wed, 11 Apr 2007 02:45:36 +0000 http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities#comment-13940 The way to avoid the third method on account signup facilities is to implement CAPTCHA, right? Is it an only counter measure? CAPTCHA is an obstacle for handicapped people. So it is difficult to avoid this vuln on a site which have an account signup facility. I think that the level of importance of this vul is low in most cases. If an adequate counter measure is not available, what do you say to a website owner (your customer)? The way to avoid the third method on account signup facilities is to implement CAPTCHA, right? Is it an only counter measure? CAPTCHA is an obstacle for handicapped people. So it is difficult to avoid this vuln on a site which have an account signup facility. I think that the level of importance of this vul is low in most cases. If an adequate counter measure is not available, what do you say to a website owner (your customer)?

]]> By: Sergey Gordeychik http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/comment-page-1/#comment-12948 Sergey Gordeychik Fri, 06 Apr 2007 03:40:13 +0000 http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities#comment-12948 Another good example of information leakage via error message is Oracle isqlplus (inurl:/isqlplus intitle:Release). If you specify wrong Connection Identifier (SID) you got ORA-12154 error, in other case - ORA-01017: invalid username/password Another good example of information leakage via error message is Oracle isqlplus (inurl:/isqlplus intitle:Release).
If you specify wrong Connection Identifier (SID) you got ORA-12154 error, in other case – ORA-01017: invalid username/password

]]> By: Jordan http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/comment-page-1/#comment-12678 Jordan Wed, 04 Apr 2007 14:58:45 +0000 http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities#comment-12678 Thanks for the writeup -- one note about the third method of using account signup forms. It seems that another prevention mechanism besides CAPTCHAS would be to make the check if the account name is taken the very last step in the signup process, so if the account doesn't exist, you've just created the account. Combine that with log monitoring such that any single IP can only sign up for x number of new accounts in y minutes. Sure, somebody could come at you with a botnet, but it's a lot harder to create and distribute an automated probing tool to a botnet than it is to run it on a single attacking server. Plus, as a last resort, you could always throw on system-wide thresholding for new accounts created so that an admin can get an email and determine whether or not the new accounts are the result of, say, a slashdotting, or just a bot trying to brute-force account names. Alternatively, you could not tell users about the account name collision until /after/ they've signed up. Make the next page after the initial account activation or password reset (via email) let them know if there's a collision. That raises the bar yet again for an attacker to try to enumerate the accounts because he's got to have a lot of valid email addresses now and an automated way to check them as a part of the brute forcing process. Thanks for the writeup — one note about the third method of using account signup forms. It seems that another prevention mechanism besides CAPTCHAS would be to make the check if the account name is taken the very last step in the signup process, so if the account doesn’t exist, you’ve just created the account. Combine that with log monitoring such that any single IP can only sign up for x number of new accounts in y minutes. Sure, somebody could come at you with a botnet, but it’s a lot harder to create and distribute an automated probing tool to a botnet than it is to run it on a single attacking server. Plus, as a last resort, you could always throw on system-wide thresholding for new accounts created so that an admin can get an email and determine whether or not the new accounts are the result of, say, a slashdotting, or just a bot trying to brute-force account names.

Alternatively, you could not tell users about the account name collision until /after/ they’ve signed up. Make the next page after the initial account activation or password reset (via email) let them know if there’s a collision. That raises the bar yet again for an attacker to try to enumerate the accounts because he’s got to have a lot of valid email addresses now and an automated way to check them as a part of the brute forcing process.

]]>