(Just a reminder that when combined with bug 1308265, it can get pretty
annoying. This is worth fixing.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/138654
Title:
Annoying and useless delays on
Is this actually going to get fixed? There hasn't been a meaningful
update in a year and a half.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/138654
Title:
Annoying and useless delays on password
** No longer affects: hundredpapercuts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/138654
Title:
Annoying and useless delays on password entry errors
To manage notifications about this bug go
What I would suggest to keep both the security and user friendliness in
entering passwords would be to add a certain number of no-delay attempts
(e.g. 3).
This way humans would get a certain number of quick retype attempts in
case of typos or different keyboard layouts (often the case with me, as
Hard-coded numbers are always bad. Why not simply make this value configurable?
Also I have to admit, I don't understand why pam_unix applies this delay. Is
this not what pam_delay (whose delay _is_ configureable) is made for?
--
You received this bug notification because you are a member of
Steve: Yes, 0.5s is a vast improvement over 2s, and I would consider
this 'fixed'.
Perhaps this should be two bugs, one paper-cut: Default password delay
is too long, and one that is (as you say) harder to fix: First few
local password attempts should be instant.
I think you can easily fix the
I would like to know what about this bug is nontrivial since there is
already a patch here.
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'm not sure the proposed patch actually addresses the original request
(is a 4x reduction in the delay, from 2 seconds to .5 seconds, that much
of an improvement?), but regardless, this is not just a usability issue,
there's also a security issue here. Any changes to the behavior of PAM
failure
Steve, are you sure? Patrick Horn's patch is a one-liner, implementing
Andy Owen's approach (3 attemps with no delay) shouldn't be hard too.
Please reconsider.
** Changed in: hundredpapercuts
Status: Invalid = New
--
Annoying and useless delays on password entry errors
** Changed in: hundredpapercuts
Status: New = Confirmed
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
this bug is not trivially fixable, so it is not a paper cut.
** Changed in: hundredpapercuts
Status: Confirmed = Invalid
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
It would be nice if you had some number of attempts (e.g. 3) with no
delay, and then after that have a delay. (e.g. 2 seconds). This way, a
brute force attack is still impossible, but the more common case of
making a typo in the password isn't annoying.
--
Annoying and useless delays on password
** Also affects: hundredpapercuts
Importance: Undecided
Status: New
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
I don't like having to use nodelay -- I like the fact that it gives a
delay when I make a mistake but 2 seconds is just too long.
I would vote for just changing the delay to 0.5 seconds, since this is
as simple as changing a constant in pam_unix
** Attachment added: This patch changes the
nodelay. $ man pam_unix for details
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
What comment do you have to add to common-auth's pam_unix to disable the
delay?
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
For most cases it's very simple to get around this by attempting a
password, killing the process after 100ms if it doesn't answer and
retrying.
This does not actually work, since as an user you are not allowed to
kill a suid root process. So you can only fork processes like hell,
which is bound
I'd set this to wontfix. Kees, do you agree?
--
Annoying and useless delays on password entry errors
https://bugs.launchpad.net/bugs/138654
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
No, but you can kill it's parent shell. You can do 'bash -c sudo
cmd' and kill bash. On my attempts this killed the sudo after a
single bad password. Sure, bash is a bit overweight and would slow
things down, but you can emulate whatever happens there with less
bloat. Or use dash, at the least.
Oh, and I can press Ctrl-C at any moment at a sudo prompt and try
again. (Depending on your POV that might be a bug in sudo, but
anyway.)
On 9/13/07, Bogdan Butnaru [EMAIL PROTECTED] wrote:
No, but you can kill it's parent shell. You can do 'bash -c sudo
cmd' and kill bash. On my attempts this
Since this is a global timeout for PAM, reducing it would change the
behavior for network services. However, as you point out, this isn't a
very effective way to discourage brute-forcing (especially for network
attempts -- it just forks another copy).
** Changed in: pam (Ubuntu)
Importance:
After a bit more reading-up I see most of this should be possible by
simply updating the default configuration in /etc/pam.d
The delay can be removed by adding parameter to common-auth's pam_unix,
and the counting by using pam_tally. I can't figure out how to add a
growing timeout; perhaps a new
22 matches
Mail list logo
