[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca3d33f1-11ef-bf33-c6ba-453a9b55b47f@bluepopcorn.net>
Date: Mon, 18 Dec 2017 11:41:08 -0800
From: Jim Fenton <fenton@...epopcorn.net>
To: passwords@...ts.openwall.com
Subject: Re: User enumeration threat in clouds
I think any time that you can design the workflow to resist enumeration
it's a good thing. But I don't consider the rate limiting features you
listed to be more than only slightly enumeration resistant -- they might
be good for brute force attacks but often the attacker has more
information than that. Suppose you wanted to determine if someone is
registered on a particular service. You might try variations on their
name, etc. and find that out despite rate limiting, and that might be a
problem in some sensitive applications (and not just Ashley Madison).
One example of doing better than this is systems that prompt for email
address and reply, "If you have an account on this system, we just sent
you an email" rather than telling the potential attacker whether the
account exists or not. (I'm ignoring for now that email is not an
acceptable method of account recovery!)
In the example you gave, perhaps it should redirect to the branded page
regardless of the username given -- maybe just fills it in on the
branded page's username field -- and then lets the user sign in there,
not giving any indication whether the username is valid or not.
-Jim
On 12/18/17 12:21 AM, Anton Dedov wrote:
> Hello friends!
>
> It is long known security practice to avoid leaking information about
> registered users in a system via different oracles. Like, unsuccessful
> authentication response or reset password workflow.
>
> Nowadays, some systems become decentralised or support external IdP
> integration, so login flow becomes two-step. E.g. system asks for a
> username@...ain at a first step and redirects user to a specific IdP /
> branded page / load-balanced instance of IdP on a second step.
>
> It's look like making such system resistant to enumeration attacks is
> harder than traditional all-in-one implementation. I mean there few
> options to follow:
> - CAPTCHA
> - Proof-of-work
> - Rate limiting per IP
>
> I understand that no rate limiting ability is probably worse than
> having some. But anyways, any of options above will not prevent
> enumeration, if attacker have some passion and time.
>
> So my question is - is it worth to spend resources on mitigating
> user-enumerating automation? And if yes, to what extent? Or may be it
> is worth to spend those efforts to better credentials bruteforcing
> prevention / monitoring?
>
> I understand that sometimes there are strong privacy requirements,
> like in Ashley Madison case, when users would not be happy to be
> exposed at all. But I am talking about traditional cloud business.
>
> --
> Anton Dedov
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
