password length limit

[andrewhodel]

Why make the limit very small, 100 characters?

I realize it needs to be allocated and that the password is stored as a salted hash that is much shorter than the possible length proving that you aren't able to allocate the exact length.

Why don't you read the input into memory to 5000 bytes instead of 100 bytes?

[andrewhodel]

Your changelog says:

- Make failure delay more consistent to avoid revealing valid usernames, set server password 
  limit of 100 characters. Problem reported by usd responsible disclosure team

If you are trying to avoid revealing valid usernames, you would know they use a single character (or the minimum) password length. You should allocate a random amount between length and 5000 to require at least 5000 providing more time for temperature to change. That makes it more difficult to guess the logins.

[mkj]

The problem is we don't know which salt to use for an invalid user. See the comment
8b4f60a#commitcomment-89492985

[andrewhodel]

@mkj meaning that the salt would be known by all who have this repository?

Why don't you make it at first execution?

[mkj]

I'll explain the details. For /etc/shadow each user has a line like

matt:$6$s0VE2ZnkcTqeBvUv$vILqFJV2lc64O/M7bjvVfBe6JJ2SvlgmJs4Tz3FWEk3CdUSGqfwsdKxNR58qjz2MB5Sc2T2uqTD2q2imgGYpc1:19488:0:99999:7:::

For Dropbear to run crypt() to check the password hash of a user (or pretend to do it for an unknown user, with a realistic time delay) it needs to pass in that $6$s0VE2ZnkcTqeBvUv first part of the crypt (or the whole thing). Dropbear doesn't want to know anything about that format, since it is basically an implementation detail of glibc, might get updated at some point in time.

So we could just read the salt of the first user in /etc/shadow, but that hasn't been implemented yet.

[andrewhodel]

It seems like you are trying to diff audio conversations of the town I live in instead of work on better products, no wonder there's no jobs.

[andrewhodel]

It's not complicated.

1. the salt is used to create a hash and the salt is hidden per operating system
2. the salt hash is provided
3. the salt hash and password hash that uses the salt is compared against the provided password

When the request is made, time is spent to gather the existing key hash and process it.

That time is measured, and based on the salt value of the OS or the salt value that is randomly set or set by this program you can guess if an account is real or not.

It's very simple, the salt value that is used when there is no account should be random.

Random values are created by subatomic particles that are sent through encased sensors. Dust in space modifies the rate of the particles.

[andrewhodel]

I'm giving you advice because I understand something and I think improvement is a requirement.

I'm asking you change the allocation maximum from 100 to 5000. It is a simple number modification. There's no reason to add to the list of contributors.

I'm giving you advice on how to use the hashing routines to reduce account name guess validity because you are working on that, most recently within this project.