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
> 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.
Salting prevents the hacker from brute forcing multiple passwords at the same time and utilizing techniques like [rainbow tables](https://en.wikipedia.org/wiki/Rainbow_table).
> 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.
The site data and the site code are stored separately. The site data is stored in the database, and is *supposed* to reach the user – well, part of it is supposed to. When you view a page on reddit, the contents of the page are extracted from the database. Hacking simply involves getting the site to give you data that it wasn’t supposed to. That said, there are ways to also leak the site code, if it isn’t stored securely.
> Theoretically if a hacker had access to the specific hash and salting being used, they could reverse-engineer the hashed passwords
No, that’s the point of hashing. Hash is a one-way function – it’s easy to calculate the hash of a given input, but it’s hard to find the input that will give a certain hash value.
> 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?
If they could *change* the code, then yes. Just because you have access to see the code doesn’t mean you can change it.
One example of a way passwords can get breached is a method known as SQLI (Sequel Injection, also known as SQL injection)
This is when unsanitized user input is directly entered into a database, like during log ins, search bars, account creation, etc. Anything with databases are potentially vulnerable. So, using SQLI, hackers are able to extract the hashed password, and sometimes the salt that’s used to hash that password.
However, the site code is stored on a server somewhere, the hackers likely don’t have a way into that server, and therefore cannot extract or change the raw code that is being used.
For your question about hackers obtaining the salt and hash for a password, you ask why they can’t reverse-engineer the hashed password. That’s simply because it’s not possible. Modern day algorithms that are encrypting these passwords have some degree of pseudo randomness, which hackers will not be able to reverse engineer without (as an example) a secret key, or something similar. However, what they can do is run the hashed password and salt through a program called HashCat. This takes in a wordlist of potential passwords, the password you want to try and crack, and some other tools that aren’t always needed. Then, the program will run every password through that hashing algorithm and salt, then compare it to the hashed password you gave it. If they match, the program stops and you have successfully cracked the password. If it ends without cracking, it means it’s run through the entire wordlist of passwords and didn’t find a correct one
There’s not that much value in site code. what are you going to do with Amazon’s code? Make a new Amazon?
All the value is in the data.
More often than not the information is stored in different places and most hacks are generally either something like SQL injection or some other site vulnerability which let’s someone access database entries they wouldn’t normally have access to. Usually this takes the form of a dump of a users table which would contain usernames, emails, and password hases etc.
This is a very different situation to a hack where someone has managed to get privelege escalation on the server itself though.
In the first example, unless the salt is stored in the clear in the database, then database dumps wouldn’t contain the salt itself. However in the second example, all bets are off – if someone has root access to the server then they probably have everything.
The reality of the situation is that there is no perfect system because quite simply, something somewhere needs to be able to turn the password into a hash to be able to authenticate a user. And if someone does have root access for any reasonable period of time then they can always reverse engineer whatever that process is. Thankfully though, these types of hack are rare compared to the ones which leak raw data.
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.
Everyone is able to access a site code, because it’s not supposed to be hidden from the user. In fact, you have it literally there in your browser, available with 2 clicks. The problem is that it’s minified, which is a process of shrinking it to the maximum, which makes it way less readable, so as a side effect, it’s difficult to figure out, but it’s doable, hard work, tho. And also a site code might get transformed e.g. if a page was coded in TypeScript, it’s converted to JavaScript first and then also minified, so you cannot go back to TypeScript, because the browser never got it. That’s just how it’s built underneath.
No, salting is done on API side (server), not by the client (site, as you call it). I haven’t worked on any project that salted password in the client.
Getting the initial value from a hashed value is damn complex operation and based on a used algorithm, it might be closer to impossible aka too meany years required or too many resources to shrink the operaton to acceptable amount of time.
I am not a hacker, but they look for any “backdoors” to the server, meaning how to execute a code, which they shouldn’t be allowed to execute. So they can e.g. execute a piece of code to get the data from database, just like the server does the same, but it’s allowed it. On the other hand, a server code is compiled, so it’s not a readable code at all, it might be a bytecode language which the runtime environment understands (what runs the server app, so to say). It is doable to read such langauge if you disassemble the source files, but those are not stored in a database and you cannot just execute a code to get you those files. Not like you can execute “give me all the users in database” command.
Latest Answers