4 ms·

No it is not, because the salt is stored in a plaintext or easily reversible format somewhere, and has to be in order for authentication to work, if you are in

No it is not, because the salt is stored in a plaintext or easily reversible format somewhere, and has to be in order for authentication to work, if you are in a position to grab the hashes, it will also be trivial to grab the salts. The point of the salt is not to add some padding bits to the password. Salts should be publicly knowable without it causing a loss of security. The one and _only_ use of a salt is to prevent precomputation attacks (rainbow tables).

bad_user 15y ago
But isn't the SSH private key also stored in plain text? I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. Or you could just install a keylogger on it and wait for the user to login. If the user's computer is compromised, a hacker could gain access to his SSH credentials. Isn't that still security by obscurity? And if you gain access to the source-code and to the database, I'm pretty sure you'll end up in a position to modify that source-code anyway, thus finding user passwords by simply logging them somewhere. Security is a complex topic and relying on the slowness of an algorithm like bcrypt doesn't make me feel any safer, as people can always come up with a faster bcrypt. Instead we should rely on computational complexity, because no matter what we do, unless quantum computers become a realy, there are limits to what we can compute when exponential complexity is involved.
- lloeki 15y ago
  > But isn't the SSH private key also stored in plain text? Not if you passphrase-protect it.
- deleted 15y ago
  [deleted]
- throwaway64 15y ago
  >But isn't the SSH private key also stored in plain text? no, passwording the key encrypts it >I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. ssh-agent does not expose the private key to clients requesting it, thats part of its design, you can however get a login session to whatever hosts it holds keys for. > Or you could just install a keylogger on it and wait for the user to login. > Isn't that still security by obscurity? That is much more involved than a hit and run attack where you download the DB, and much more likely to be detected/detectable before any harm is done, via such things as IDS, or just plain not possible due to how a system is locked down (stuff like ssh gateways that are heavily secured, etc). All this stuff is besides the point anyways, bcrypt/hashed passwords are not about protecting your system from active compromise directly, but its about limiting the damage such compromises can do. >relying on the slowness of an algorithm like bcrypt the point of bcrypt isnt JUST that it is slow, its that each step requires the data from the previous step, many thousands (or tens of thousands, or even millions) of times over, that makes it impossible to parallelize across many GPU cores or similar arrangements, thats a huge part of the weakness of stuff like plain hashing/salting, its trivial to parallelize and to scale up that parellelization till you are generating billions, or even trillions of hashes a second, that approch is totally useless on bcrypt. Another important factor in bcrypt is that you can up the amount of rounds trivially without having everyone reset their passwords, so your password DB can get stronger as technologies advance.
- derleth 15y ago
  From throwaway64, who is dead: ">But isn't the SSH private key also stored in plain text? no, passwording the key encrypts it >I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. Or you could just install a keylogger on it and wait for the user to login. ssh-agent does not expose the private key to clients requesting it, thats part of its design, you can however get a login session to whatever hosts it holds keys for. > Isn't that still security by obscurity? That is much more involved than a hit and run attack where you download the DB, and much more likely to be detected/detectable before any harm is done, via such things as IDS, or just plain not possible due to how a system is locked down (stuff like ssh gateways that are heavily secured, etc). >Instead we should rely on computational complexity ... there are limits to what we can compute when exponential complexity is involved. the point of bcrypt isnt JUST that it is slow, its that each step requires the data from the previous step, many thousands of times over, that makes it impossible to parallelize across many GPU cores or similar arangements, thats a huge part of the weakness of stuff like plain hashing/salting, its trivial to parallelize and to scale up that parellelization till you are generating billions, or even trillions of hashes a second, that approch is totally useless on bcrypt."
- eru 15y ago
  > Instead we should rely on computational complexity, because no matter what we do, unless quantum computers become a realy, there are limits to what we can compute when exponential complexity is involved. Quantum computing does not help with exponential problems in general.

bad_user 15y ago

But isn't the SSH private key also stored in plain text? I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. Or you could just install a keylogger on it and wait for the user to login. If the user's computer is compromised, a hacker could gain access to his SSH credentials. Isn't that still security by obscurity? And if you gain access to the source-code and to the database, I'm pretty sure you'll end up in a position to modify that source-code anyway, thus finding user passwords by simply logging them somewhere. Security is a complex topic and relying on the slowness of an algorithm like bcrypt doesn't make me feel any safer, as people can always come up with a faster bcrypt. Instead we should rely on computational complexity, because no matter what we do, unless quantum computers become a realy, there are limits to what we can compute when exponential complexity is involved.

lloeki 15y ago
> But isn't the SSH private key also stored in plain text? Not if you passphrase-protect it.
deleted 15y ago
[deleted]
throwaway64 15y ago
>But isn't the SSH private key also stored in plain text? no, passwording the key encrypts it >I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. ssh-agent does not expose the private key to clients requesting it, thats part of its design, you can however get a login session to whatever hosts it holds keys for. > Or you could just install a keylogger on it and wait for the user to login. > Isn't that still security by obscurity? That is much more involved than a hit and run attack where you download the DB, and much more likely to be detected/detectable before any harm is done, via such things as IDS, or just plain not possible due to how a system is locked down (stuff like ssh gateways that are heavily secured, etc). All this stuff is besides the point anyways, bcrypt/hashed passwords are not about protecting your system from active compromise directly, but its about limiting the damage such compromises can do. >relying on the slowness of an algorithm like bcrypt the point of bcrypt isnt JUST that it is slow, its that each step requires the data from the previous step, many thousands (or tens of thousands, or even millions) of times over, that makes it impossible to parallelize across many GPU cores or similar arrangements, thats a huge part of the weakness of stuff like plain hashing/salting, its trivial to parallelize and to scale up that parellelization till you are generating billions, or even trillions of hashes a second, that approch is totally useless on bcrypt. Another important factor in bcrypt is that you can up the amount of rounds trivially without having everyone reset their passwords, so your password DB can get stronger as technologies advance.
derleth 15y ago
From throwaway64, who is dead: ">But isn't the SSH private key also stored in plain text? no, passwording the key encrypts it >I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. Or you could just install a keylogger on it and wait for the user to login. ssh-agent does not expose the private key to clients requesting it, thats part of its design, you can however get a login session to whatever hosts it holds keys for. > Isn't that still security by obscurity? That is much more involved than a hit and run attack where you download the DB, and much more likely to be detected/detectable before any harm is done, via such things as IDS, or just plain not possible due to how a system is locked down (stuff like ssh gateways that are heavily secured, etc). >Instead we should rely on computational complexity ... there are limits to what we can compute when exponential complexity is involved. the point of bcrypt isnt JUST that it is slow, its that each step requires the data from the previous step, many thousands of times over, that makes it impossible to parallelize across many GPU cores or similar arangements, thats a huge part of the weakness of stuff like plain hashing/salting, its trivial to parallelize and to scale up that parellelization till you are generating billions, or even trillions of hashes a second, that approch is totally useless on bcrypt."
eru 15y ago
> Instead we should rely on computational complexity, because no matter what we do, unless quantum computers become a realy, there are limits to what we can compute when exponential complexity is involved. Quantum computing does not help with exponential problems in general.