On Tue 29/6/2021, at 9:47 pm, roy...@gmail.com wrote:
>
>> That itself wouldn't be a problem if we could just crypt all incoming
>> password attempts before checking a username's existence - the problem is
>> that the password crypt algorithm can vary per user, so the time will vary
>> too. We
Hello Matt,
Matt Johnston wrote:
>
> Hi Roy,
>
> On Tue 29/6/2021, at 7:18 pm, roy...@gmail.com wrote:
>
>
> - Make failure delay more consistent to avoid revealing valid usernames, set
> server password
> limit of 100 characters. Problem reported by usd responsible disclosure team
>
>
> What
Hi Roy,
On Tue 29/6/2021, at 7:18 pm, roy...@gmail.com wrote:
>
>> - Make failure delay more consistent to avoid revealing valid usernames, set
>> server password
>> limit of 100 characters. Problem reported by usd responsible disclosure team
>
> What is the technical reason of limiting
Hi,
Sorry for replying such old message, but:
Matt Johnston wrote:
>
> Hi all,
>
> At long last Dropbear 2019.77 is released. Most changes are
> bug fixes, with a few small features. There are security
> fixes to avoid revealing the existence of valid usernames.
>
>
Beware that dbclient in 2019.77 has a regression, it won't
reset TTY modes on exit. That's fixed in
https://secure.ucc.asn.au/hg/dropbear/rev/4b01f4826a29
Cheers,
Matt
On Sat, Mar 23, 2019 at 10:02:49PM +0800, Matt Johnston wrote:
> Hi all,
>
> At long last Dropbear 2019.77 is relea
>>>>> "Matt" == Matt Johnston writes:
> Hi all,
> At long last Dropbear 2019.77 is released. Most changes are
> bug fixes, with a few small features. There are security
> fixes to avoid revealing the existence of valid usernames.
Thanks. Can you p
Hi all,
At long last Dropbear 2019.77 is released. Most changes are
bug fixes, with a few small features. There are security
fixes to avoid revealing the existence of valid usernames.
This release also merges the fuzzing branch. In a
normal build this should have no effect on operation