The current UX is terrible, it explicitly lies to the user, as was explained in my earlier message, and someone else explaining systems now say that either username or login being wrong, but not which one.
Same here, if you're adding a third thing, simply say that the third thing could also be the reason behind the failed login attempt. "Wrong username, wrong password, or login timeout is active" If you disagree with this, do explain how Frederic should have known the timeout even existed, think whether that's a good UX, and if it can perhaps be improved by informing the user. Martin On Sat, Apr 13, 2024, 01:39 mpan <archml-y1vf3...@mpan.pl> wrote: > > Are you sure you're not just hitting the new(old at this point) > > idiotic default of always failing after X failed attempts in Y time? > > That would mean you mistyped the password a few times, but afterwards > > it would not matter even if you typed it correctly. > Hello. This is a response not only to the above message, but also to > many down in this thread. > > If one has a strong passphrase configured, understands basic > security, and happens to be on their local home computer, faillock may > be configured to use different options. For example I have it ~turned > off altogether⁽¹⁾ and so do many people in a similar situation. > > The defaults are meant to provide sane security in the baseline case. > Not only in faillock, but with everything. One installs a package, it > doesn’t do something risky by default. Sounds reasonable, doesn’t it? > And in the baseline case a 15 minutes lock after 3 failed logins in 10 > minutes provides between a few hours to a day delay for the adversary, > giving the sys/net admin enough time to detect and react. A 15 minute > lock is also reasonably tamper-evident for the baseline case user. > > You may dislike UX decision, but you should get used to it: because > now this becomes common best practice, in particular for network-facing > services. The primary reason is avoiding side channel attacks, leading > to the basic secure implementation not being able to distinguish between > these two cases. Even where it could be possible, per WSTG-IDNT-04 it > shouldn’t be possible to make such distinction. That’s not only a > security feature, but also a user privacy improvement. > > Please be aware, that in the model the message goes not to an > authorized user. Obviously it can’t, given the authorization has failed. > Which means the recipient is an actor not permitted to receive this > information. The always-authorized actor is the administrator and they > have access to the detailed cause: it’s in the logs. > > Of course one may invent an edge case, where this isn’t needed. But > mere existence of such cases is not really relevant, when they are not > representative of the entire landscape. > > So please consider changing tone a bit; cheers. > ____ > ⁽¹⁾ 999 attempts, 1 s lock. > >
