I’m in the process of familiarizing myself with the ins and outs of password security, and what level of screwed you are depending on how a site treated password security before a breach occured.
What I understand so far is that if a site stores plaintext passwords and they’re leaked, anyone can instantly use them to access your account. If the passwords have been hashed, they’re more or less back to brute-forcing passwords and hoping the hash matches. If passwords are salted, extra data is added to the hashes, but (from what I understand) since this is also handled by the site (when you try to log in your password is hashed and salted before being compared to what they have saved), this doesn’t actually change the effectiveness of brute-forcing. I might be missing something here.
Either way, what I’d like to know is how do sites keep the site code itself inaccessible from hackers, if site data, like tables containing user information, can be obtained. Theoretically if a hacker had access to the specific hash and salting being used, they could reverse-engineer the hashed passwords, right? But they don’t, and I don’t understand why they don’t, when they seem to be able to access other data. In previous answers on this topic I’ve seen people say that if hackers had access to site code they could just remove the necessity for a password, or otherwise get around those restrictions, but why can’t they get this access?
In: 15
So there are a few questions here:
>If passwords are salted, extra data is added to the hashes, but (from what I understand) since this is also handled by the site (when you try to log in your password is hashed and salted before being compared to what they have saved), this doesn’t actually change the effectiveness of brute-forcing.
When passwords are leaked, that’s usually the hashed form. A lot of hashed password lists have been leaked in the past, and have been brute forced to retrieve the original passwords. Using unique salts in your own website ensures that if people use a breached password for your site, the hash will still be different. This way when your hashed passwords were to leak, they would need to brute force it all over to find the real passwords instead of being able to recognize identical hashes. Note that reusing passwords is still a very bad idea, since using the breached password will still work on your site without needing to reverse the hashed version!
>Theoretically if a hacker had access to the specific hash and salting being used, they could reverse-engineer the hashed passwords, right?
Well no, since hashing is a one-way encryption it’s impossible to reverse the hashing function even if you know the hash.
> In previous answers on this topic I’ve seen people say that if hackers had access to site code they could just remove the necessity for a password, or otherwise get around those restrictions, but why can’t they get this access?
Databases are simple: you have data and you store it. Code is a lot more complex, and there are a lot of steps in between the code that the developers write and the one that runs on the servers. If you’re at a point where you have system access to databases and servers, it’s way easier to just export all the data than to manipulate the server code.
Latest Answers