Adding Secure Passwords to Linux

[John Savard]

I just encountered an article saying that, since today's GPUs are so
powerful, there's no such thing as a secure password any more.
The death of the password is a bad thing, because smartphones
can get lost, broken, or bricked. Indeed, if people have to use
smartphones to log on to everything, they will be the new high-value
target.
However, Linux can set an example of how to make passwords work.
Using a GPU to brute-force a password requires an attacker
to have gotten a copy of the password file from the target
machine - that's how an attacker can try zillions of passwords, instead
of being locked out after three failed attempts, each of which took
several seconds.
So if one changed how password files stored passwords...
Use a better hash function.
Use 128-bit salt.
Use Blowfish encryption as a stage in the process.
So when a Linux system is installed, a random and unique key is
generated for the encryption phase in checking passwords against
the password file.
Of course, that unique key still has to be stored somewhere on the
system, so an attacker could still obtain it. Another possibility too...
*most* cryptographic algorithms today are careful to avoid any
conditional branch operations, because they're conducive to attacks
which grab the key by monitoring power consumption. But such an
algorithm - one that does use a lot of conditional branches - would be
hard to implement efficiently on a GPU.

John Savard

[Richard Kettlewell]

John Savard <quad...@gmail.com> writes:

> I just encountered an article saying that, since today's GPUs are so
> powerful, there's no such thing as a secure password any more.
> The death of the password is a bad thing, because smartphones
> can get lost, broken, or bricked. Indeed, if people have to use
> smartphones to log on to everything, they will be the new high-value
> target.
> However, Linux can set an example of how to make passwords work.
> Using a GPU to brute-force a password requires an attacker
> to have gotten a copy of the password file from the target
> machine - that's how an attacker can try zillions of passwords, instead
> of being locked out after three failed attempts, each of which took
> several seconds.
> So if one changed how password files stored passwords...
> Use a better hash function.

Have a look at scrypt or argon2, designed specifically for password
hashing.

--
https://www.greenend.org.uk/rjk/

[Marco Moock]

On Thu, 28 Jul 2022 11:25:49 -0700 (PDT)
John Savard <quad...@gmail.com> wrote:

> I just encountered an article saying that, since today's GPUs are so
> powerful, there's no such thing as a secure password any more.

I depends on the length. Longer passwords are better. The process of
cracking passwords when a hash table is available, even if salted, is
decreasing because GPUs become faster and this process can easily be
split on many machines.
There are some steps that can increase the time:

Longer passwords (The amount of time needed increases exponential with
the length of the pw)
unique salts per password (Then every password must be tested
individually per user hash and not only one time for all users with the
same salt)

Privileges that deny normal users access to the hashed passwords, like
most Linux distributions use /etc/shadow and don't allow read access to
users.

--
Gruß
Marco

[Spiros Bousbouras]

On Fri, 29 Jul 2022 08:36:57 +0200
Marco Moock <mo...@posteo.de> wrote:
> On Thu, 28 Jul 2022 11:25:49 -0700 (PDT)
> John Savard <quad...@gmail.com> wrote:
>
> > I just encountered an article saying that, since today's GPUs are so
> > powerful, there's no such thing as a secure password any more.
>
> I depends on the length. Longer passwords are better. The process of
> cracking passwords when a hash table is available, even if salted, is
> decreasing because GPUs become faster and this process can easily be
> split on many machines.
> There are some steps that can increase the time:
>
> Longer passwords (The amount of time needed increases exponential with
> the length of the pw)

Assume that an attacker can test 10**12 passwords per second. Lets say
that we create a password using an alphabet which has
A-Z a-z 0-9 ,.

which makes it a round (in binary !) 64 characters. If we have a uniform
random way to pick a character for each position of the password then
in order to brute force a password with 16 characters would take

64**16 / (10**12 * 3600 * 24 * 366) = 2505444321 years

where I have assumed for simplicity that each year has 366 days.

Is there something seriously wrong with my calculations ? If not then
I don't see a problem. For picking uniform random values ,
/dev/random and /dev/urandom fit the bill.

--
Advances in the psychic and related sciences may bring means of
exploring unexpressed beliefs, thoughts and emotions.
MR. JUSTICE BRANDEIS
http://supreme.justia.com/cases/federal/us/277/438/case.html

[John McCue]

John Savard <quad...@gmail.com> wrote:
> I just encountered an article saying that, since today's GPUs are so
> powerful, there's no such thing as a secure password any more.

If you do not allow remote logins to your system I would
not worry about this. Full disk encryption should solve
your main concern. But you may need to worry about your
luks setup. Of course, if people get physical access to
your system, all bets are off.

If allowing ssh(1), disable the use of passwords and enable
ssh keys.

If you are worried about local users, then you can enable
acct(2) and look for suspicious activates. But in reality,
you should only let trusted users on your system :)

<snip>
>
> John Savard

Regards
John

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

[Allodoxaphobia]

On Sun, 11 Jun 2023 10:30:40 -0000 (UTC), Spiros Bousbouras wrote:
> On Fri, 29 Jul 2022 08:36:57 +0200
> Marco Moock <mo...@posteo.de> wrote:
>> On Thu, 28 Jul 2022 11:25:49 -0700 (PDT)
>> John Savard <quad...@gmail.com> wrote:
>>
>> > I just encountered an article saying that, since today's GPUs are so
>> > powerful, there's no such thing as a secure password any more.
>>
>> I depends on the length. Longer passwords are better. The process of
>> cracking passwords when a hash table is available, even if salted, is
>> decreasing because GPUs become faster and this process can easily be
>> split on many machines.
>> There are some steps that can increase the time:
>>
>> Longer passwords (The amount of time needed increases exponential with
>> the length of the pw)
>
> Assume that an attacker can test 10**12 passwords per second.

What internet-facing firewall would entertain 10**12 password attemps
per second?!?!

[Spiros Bousbouras]

On 12 Jun 2023 12:35:50 GMT

That's besides the point. The posts I quoted address the issue of whether
GPUs are so powerful that you can't create a password of reasonable length
which cannot be cracked through brute force. I provided a simple calculation
which suggests that , even with an attacker with extraordinary computing
power available , a password with only 16 characters would be safe.

--
vlaho.ninja/prog

[Richard Kettlewell]

The threat model is an attacker who has acquired a collection of hashed
passwords; they then attack them on their own equipment via exhaustive
search.

Measuring the attacker in terms of attempts per second isn’t always very
useful though, since the attack scales extremely well. 10^18 SHA256
hashes per second is within human civilization’s capacity for example.

A common approach is to estimate the money cost of recovering a password
of a given complexity, for instance based on the cost of renting GPU
capacity from a cloud service provider.

--
https://www.greenend.org.uk/rjk/

[Bit Twister]

Surprised during speed calculation discussion no one has mention rainbow tables.
https://en.wikipedia.org/wiki/Rainbow_table


Also is what type of attack? If guessing in during login there would be
the authorization failure delay to add to the crack duration time.

[David W. Hodgins]

On Tue, 13 Jun 2023 09:10:57 -0400, Bit Twister <BitTw...@mouse-potato.com> wrote:
> Surprised during speed calculation discussion no one has mention rainbow tables.
> https://en.wikipedia.org/wiki/Rainbow_table

The salting of passwords makes rainbow tables useless, so doesn't matter anymore.

Rainbow tables are only a factor if an old non-salted method is used. Even then,
it only comes into play if they are a local user or the system has been partly
hacked already so the attacker has access to /etc/shadow.

> Also is what type of attack? If guessing in during login there would be
> the authorization failure delay to add to the crack duration time.

Yes. Also lockouts after X failed attempts, though that can also result in
denial of service attacks against the real user.

A lot of fear over password guessing is due to tv shows that show a hacker
running a program that knows when it's got the first character, and then
the second, etc. Reality is that the password is either correct or incorrect.
Very few systems let the attacker know how many, if any, of the characters are
correct. It would require having the correct password already available to the
login program in clear text.

Fear over brute force attacks against things like ssh is due to people having
a vary hard time understanding just how big a number 2^128 really is.
https://discover.hubpages.com/technology/how-big-is-2-to-the-power-128

When people ask me for a recommendation on passwords, I tell them to use
a mix of words and numbers that mean something to them, but that others
will not be able to guess even if they know them well.

For example, use the number from the address of some building you know of,
and the name of a street, and the name of a pet. These can be taken from
real life or from something you've seen somewhere such as a show or news
report. Put all three of them together to make the password.

The important thing is that the password is too long to brute force, isn't in
any of the lists of commonly used passwords, and be some combination of words
and numbers that you will have no trouble remembering.

Regards, Dave Hodgins

[Spiros Bousbouras]

On Mon, 12 Jun 2023 16:46:28 +0100

Richard Kettlewell <inv...@invalid.invalid> wrote:
> The threat model is an attacker who has acquired a collection of hashed
> passwords; they then attack them on their own equipment via exhaustive
> search.
>
> Measuring the attacker in terms of attempts per second isn’t always very
> useful though, since the attack scales extremely well.

The defence also scales extremely well , you just add a few more characters
to the password. So how many more characters does one need per GPU an
attacker can throw at the problem ?

> 10^18 SHA256
> hashes per second is within human civilization’s capacity for example.

64**16 / (10**18 * 3600 * 24 * 366) = 2505 years

Seems pretty safe to me.

> A common approach is to estimate the money cost of recovering a password
> of a given complexity, for instance based on the cost of renting GPU
> capacity from a cloud service provider.

A more "objective" criterion is electricity consumption. So how many
watts of electricity would it take to do 10^18 SHA256 hashes per second ?

--
vlaho.ninja/prog

[Richard Kettlewell]

Spiros Bousbouras <spi...@gmail.com> writes:
> Richard Kettlewell <inv...@invalid.invalid> wrote:
>> The threat model is an attacker who has acquired a collection of
>> hashed passwords; they then attack them on their own equipment via
>> exhaustive search.
>>
>> Measuring the attacker in terms of attempts per second isn’t always
>> very useful though, since the attack scales extremely well.
>
> The defence also scales extremely well , you just add a few more
> characters to the password. So how many more characters does one need
> per GPU an attacker can throw at the problem ?

I don’t agree that passwords scale ‘extremely well’ - the longer a
password is the harder it is to remember, and end users start using a
variety of tricks to avoid having to do so, e.g. repeated components,
sequences of dictionary words, etc. The real search space does not
actually expand as fast as you would think.

>> 10^18 SHA256
>> hashes per second is within human civilization’s capacity for example.
>
> 64**16 / (10**18 * 3600 * 24 * 366) = 2505 years
>
> Seems pretty safe to me.
>
>> A common approach is to estimate the money cost of recovering a password
>> of a given complexity, for instance based on the cost of renting GPU
>> capacity from a cloud service provider.
>
> A more "objective" criterion is electricity consumption. So how many
> watts of electricity would it take to do 10^18 SHA256 hashes per second ?

Money seems more objective to me, given that’s the resource someone has
to actually spend to recover a password, and to measure against the
value of the password. There is zero point spending $1M (whether
directly on power, or indirecly as cloud GPU rental) to recover a
password that you can only exploit for $1000 of value.

--
https://www.greenend.org.uk/rjk/

[Spiros Bousbouras]

On Fri, 16 Jun 2023 08:29:04 +0100
Richard Kettlewell <inv...@invalid.invalid> wrote:

> Spiros Bousbouras <spi...@gmail.com> writes:
> > A more "objective" criterion is electricity consumption. So how many
> > watts of electricity would it take to do 10^18 SHA256 hashes per second ?
>
> Money seems more objective to me, given that’s the resource someone has
> to actually spend to recover a password, and to measure against the
> value of the password. There is zero point spending $1M (whether
> directly on power, or indirecly as cloud GPU rental) to recover a
> password that you can only exploit for $1000 of value.

I meant objective in the sense that electricity consumption is only dependent
on technology and physics whereas monetary value also introduces a vast new
parameter which is economic factors which depends on politics. As for "zero
point" , people can have other motivations for wanting to break into someone's
computer rather than (just) money.

--
vlaho.ninja/prog