-2

I know hardly anything about this stuff but I am interested in cryptography and online security. I'm just wondering when a hacker tries to brute force their way into a system they need to find the hashed password, the salt and the hash function. Where and how do they actually find these in an online form?

Andy Waltz
  • 1
  • 1
  • 1
    They are not in a "form" really. The hash and the salt is in the database. What hash function it is can usually be determined from the hash, or it can be read from the server side source code. – Anders Jan 15 '18 at 08:36

1 Answers1

0

The password is normally sent in plaintext over an encrypted connection to the server. The server then calculates the hash of the password and compares it against the entry in the database.

The hash and salt are stored in the database together. The hash function is coded into the application. For applications which support multiple hash functions (usually for changing the hash function in future) there may be a flag to suggest which algorithm was used for that particular password. The hash storage format may also offer clues as to which algorithm was used (hash length can be an indicator. Formats like bcrypt store the details of what is used directly). Alternatively someone with a copy of the authentication database tables can attempt common passwords with an assortment of algorithms until they find a hash that exists.

when a hacker tries to brute force their way into a system they need to find the hashed password, the salt and the hash function

This isn't true. A hacker that has obtained a copy of the authentication database tables may try to reverse the hashes. This is useful because many users re-use credentials. There are many ways to obtain a copy of the tables - including but not limited to finding an exploitable channel to gain a shell (command prompt / terminal where you can execute commands directly) on the server, SQL injection, the database being open to the internet with default credentials or a tired developer accidentally checking in access tokens to a public git repository.

To do so you would normally try large lists of common passwords, common dictionary words and for ~9 characters a full brute force. This usually results in reversing a large percentage of the available hashes.

Hector
  • 10,893
  • 3
  • 41
  • 44
  • Thanks for the quick response Hector! I may have misinterpreted what you said but are you saying that without first breaching the database, the hacker can not crack a password? – Andy Waltz Jan 15 '18 at 09:55
  • @AndyWaltz - You can brute force a password against a service. But for that you don't require the hash/salt. You just send the username + password to the service for a range of passwords until you find the correct one. But this is slow in the best case and easily slowed to unusable (unless you can narrow the users password to a handful of options) with server side restrictions. – Hector Jan 15 '18 at 09:58
  • OK thanks so much. You helped me understand this much better, so... a fully secure database is pretty much unhackable? – Andy Waltz Jan 15 '18 at 10:24
  • EDIT: I phrased that really badly, I meant to ask that without first hacking the database, a hacker can't practically crack a password? – Andy Waltz Jan 15 '18 at 10:32
  • @AndyWaltz - If its not on one of the 10,000 most common passwords lists, a secure password its not practical to brute force it. There are other approaches - Man in the Middle'ing the connection to the server for example - but if the connection is using HTTPS this should not be possible. – Hector Jan 15 '18 at 10:35