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.