[wp-hackers] Limit Login Attempts
Simon Prosser
pross at pross.org.uk
Thu Apr 25 19:13:51 UTC 2013
In the spirit of this thread i created a plugin too:
https://gist.github.com/Pross/5461836
No api, no pissing about, just blocks.
Of course its never going to be as good as http server level block.
On 25 April 2013 02:13, Mark Costlow <cheeks at swcp.com> wrote:
> I agree that obscurity isn't a correct approach to true safety.
> Sometimes I still find it useful to add some obscurity to slow them
> down a little. Especially if it's easy to do and doesn't burden the
> user (i.e. not making the admin username a meaningless string of
> characters).
>
> In my environment I can control the initial admin username and
> initial password. Unsophisticated users are unlikely to change the
> admin username. They're more likely to change the password, and
> soemtimes they do it in a stupid way no matter how hard we try to
> keep them from doing it. Obscuring the username a bit keeps
> them from becoming the lowest hanging fruit.
>
> Anyway, in playing with the /?author=N requests, I found that it does
> give up the login name even if that user has not authored any posts.
> The HTML output contains:
>
> <body class="archive author author-username author-2 custom-font-enabled
> single-author">
>
> ... where "username" is the name of author N.
>
> Thanks,
>
> Mark
>
>
> On Wed, Apr 24, 2013 at 07:07:26PM -0500, Otto wrote:
> > On Wed, Apr 24, 2013 at 6:20 PM, Mark Costlow <cheeks at swcp.com> wrote:
> > > One of our customer sites had a related problem today. A brute-force
> > > attacker can learn the names of any potential admin users by sending
> > > GET requests for /?author=N where N is a user number.
> >
> > First, note that users without published posts will not get the
> > redirect from the ?author=N requests. Only published authors will. So
> > don't publish using admin credentials and this is mitigated.
> >
> > On a wider note, however, usernames are not meant to be considered
> > private information, and efforts to hide or treat them as private are
> > misguided and potentially harmful. I realize that this is
> > counter-intuitive, so allow me to explain:
> >
> > Let's consider the consequences if usernames were intended to be
> > "hidden" information. If the username was considered secret, then the
> > total attack-surface for brute forcing a password would increase,
> > because now the attacker must learn both the username and the password
> > to gain entry. Instinctively, one might think of this as a good thing,
> > but you have to factor in the human element as well.
> >
> > For years and years and years, the tech community as a whole has tried
> > to drive home the point of "choose a good password". At least some
> > users have done this, and the point is well received. However, nobody
> > has ever really said "choose a hard-to-guess username too". It's not a
> > point to be driven home, and it's not intuitive. People tend to use
> > simple, alphabetic usernames. So from a security standpoint, treating
> > the username as "sensitive info" is problematic.
> >
> > More to the point, if we assume the user has a good password to begin
> > with, then having an easy to find username doesn't really help the
> > attacker any. It's already basically impossible to brute force a
> > "good" password. Adding the username to it really is identical to
> > increasing the password length, but the problem is that people haven't
> > had "choose a hard username" drilled into them. So the username's
> > "difficulty" level isn't anywhere near what they're likely to pick for
> > a password. A username is, essentially, an extremely poor password,
> > given normal human behavior.
> >
> > So, treating usernames as secret is a bad idea, because it adds user
> > confusion. If they already have a good password, then their username
> > doesn't really matter. Asking them to choose a difficult username too
> > adds complexity, and people are bad at complexity. If you increase the
> > security requirements too much, you end up with the "password on a
> > post-it note on the monitor" syndrome. You need to balance good advice
> > with how likely people are to actually take that advice.
> >
> > Additionally, many modern webservices have eschewed usernames
> > entirely, in favor of email addresses. Google, Facebook, etc, these
> > have no user names at all. Finding out an email address is easy (you
> > can see mine in this email, after all). Does the fact that you know my
> > email address make it any easier for you to crack my GMail account?
> > I'm guessing not, because I have a good password (and I use 2-factor
> > auth, but that's beside the point).
> >
> > Yes, the username can sometimes be gotten from an ?author=N method.
> > But it can be gotten in other ways too. And, it's irrelevant except in
> > a targeted attack, and that sort of attack is doomed to failure if the
> > password is a good one to begin with. Encourage good password
> > selection, and don't confuse users by encouraging extra and somewhate
> > unnecessary security measures as well.
> >
> > That's my 2 cents.
> >
> > -Otto
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> --
> Mark Costlow | Southwest Cyberport | Fax: +1-505-232-7975
> cheeks at swcp.com | Web: www.swcp.com | Voice: +1-505-232-7992
>
> Mail Minder - Intelligent Push Notifications for Email on the iPhone
> http://mailminderapp.com/download or in the App Store
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
--
My Blog: http://pross.org.uk/
Plugins : http://pross.org.uk/plugins/
Themes: http://wordpress.org/extend/themes/profile/pross
More information about the wp-hackers
mailing list