[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Jun 2016 11:16:30 +0200 (ora legale Europa occidentale)
From: Marco Ivaldi <raptor@...iaservice.net>
To: passwords@...ts.openwall.com
Subject: Re: Am I Overlooking any Practical Attacks?
Hello Scott,
On Sun, 19 Jun 2016, Scott Arciszewski wrote:
> More importantly, I'm trying to eliminate the practical exploits against
> user authentication systems. I'd like to think I've covered most of
> them, but if anyone has any avenues for exploitation that I hadn't
> already addressed (except for "implant malware on the user's computer
> and log keystrokes" types of attacks, obviously), I would love to hear
> about them.
The list of security features that you've provided looks quite complete.
In addition to those features, you might want to implement some
anti-phishing techniques that allow users to authenticate the web server
as legitimate (e.g. selection of a personal image and display of such
image at logon).
For an even more robust authentication I'd recommend implementing logging
and alarm mechanisms that can alert users/admins in case of unusual (e.g.
account recovery/password reset, modification of account data), anomalous
(e.g. multiple invalid logon attempts), or otherwise suspicious (e.g.
logon at unusual times or from unusual locations) activities.
Also related to attack detection and alerting, Canary Tokens
(http://canarytokens.org/) and accounts with deliberately weak passwords
that trigger an alarm when accessed look promising.
> Current security features that will be implemented as of v0.3.0 (releasing soon):
>
> * Weak passwords are rejected. Weak means a Zxcvbn score < 3 (this
> parameter can be configured). The rejection takes place server-side, but
> we also use zxcvbn.js to give users immediate feedback. Consequently,
> one of the 10,000 most common passwords will be accepted. The password
> feedback messages also strongly encourage the use of password managers.
What about password expiration? Did you deliberately choose not to
implement it?
> * Account recovery: Most importantly, it's optional. Users can uncheck a
> box to prevent this from being used as a backdoor. Alternatively, they
> can leave it enabled and provide a PGP public key. Or they can throw
> caution to the wind and trust STARTTLS to not get stripped. The actual
> password recovery email contains a two-part random token (modeled after
> the long-term authentication tokens) that expires in (by default) an
> hour. There also exists a configuration option that invalidates all of
> the user's other browsing sessions the second they change their
> password.
This is very good practice. In case you store sensitive data in the
account (e.g. payment card numbers), I also suggest to remove them upon
account recovery.
> * Login and account recovery attempts have progressive throttling --
> based on IP subnet (configurable by the site administrator; defaults to
> /32 for IPv4 and /48 for IPv6) or username. You can set the initial
> delay (default: 250ms) and the cap (default: 30s); it will double with
> each successive failed attempt. This helps to prevent users from
> hammering the RAM/CPU with a barrage of Argon2i calculations and
> amplifying a DDoS attempt. The delay can be configured in two modes:
> fast-exit (aborts and tells them to wait a while before trying again) or
> sleep (avoids a UX wart, but is worse for security -- an attacker might
> be able to use this to fill up the worker process pool and block
> legitimate traffic). Conversely, in the fast-exit case, someone who
> guesses your username would be able to deny a specific user from logging
> in.
How are the usernames generated? In case you have an easily guessable
scheme (e.g. userNNNN where NNNN is a number), an attacker might be able
to exploit account lockouts/throttling to cause a DoS condition.
I hope this helps. Good luck with your project,
--
------------------------------------------------------------------
Marco Ivaldi OPSA, OPST, OWSE, PCI QSA,
Senior Security Advisor PCI ASV, PRINCE2 Foundation
@ Mediaservice.net Srl Tel: +39-011-32.72.100
Via Santorelli, 15 Fax: +39-011-32.46.497
10095 Grugliasco (TO) - ITALY http://www.mediaservice.net/
------------------------------------------------------------------
PGP Key - https://keys.mediaservice.net/m_ivaldi.asc
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.
