Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALnMstV=bCidc_qG0NvyxgCgL3K5e9F1g=N74SsJGCb-3OOQuA@mail.gmail.com>
Date: Mon, 18 Dec 2017 11:21:03 +0300
From: Anton Dedov <adedov@...il.com>
To: passwords@...ts.openwall.com
Subject: User enumeration threat in clouds

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.