[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALnMstWdVPLNb7CSERJCn=4xWQ=G3dpDHMZ89Ytv=PDoo7O-Dg@mail.gmail.com>
Date: Wed, 20 Dec 2017 08:50:13 +0300
From: Anton Dedov <adedov@...il.com>
To: passwords@...ts.openwall.com
Subject: Re: User enumeration threat in clouds
Jim,
Thank you!
Yes, I thought about redirecting non-existent user to a random tenant, but
it may hurt user experience a lot, when a user has a small typo in a
username...
On Mon, Dec 18, 2017 at 10:41 PM, Jim Fenton <fenton@...epopcorn.net> wrote:
> 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
>
>
>
--
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.
