Once again you are avoiding to answer this simple question, because you know there lies the truth and you can't have it.
Why is storing a hash of a password less secure than storing a hash of a password and storing a salt for it?
Don't answer, you can't, you are programmed not to be able to answer this, in the face of the obvious inconsistency you shy away from thinking about it falling onto a pre-programmed reaction.
It is also funny how you believe that this specific issue is going to lead to my systems 'getting owned' without knowing anything about my systems. Thus another pre-programmed reaction, which is also nonsense and it leads me to conclude that you are useless and I wouldn't have you anywhere near my systems.
I kid you not, I was in a in Germany store about 2 months ago, there was a bunch of tourists, a couple came to a meat counter and the guy said: "I would like 100 kilograms" of some sausage. The woman at the counter looked funny at him and I intervened knowing how punctual the Germans sometimes are.
Right, at 3 months she was yelling so loud, some people left the room. At 6 months she really yelled less.
However consider that an injection into the leg muscles of 2 full syringes with 6 vaccines at once is truly painful even for an adult, why should a 3 or 6 months old suck it up?
Passwords are useless in the first place, and that is what you can't understand. If I relied on passwords for security, I wouldn't have any security at all. My users don't care about passwords so I can't rely on them to keep them secret because they don't.
Thus the argument that I have to invest more time into a password protecting mechanism is stupid and someone making it to me is a snake oil salesman. Twice so, for insisting that storing hashes cannot be secure but storing salt is.
If anybody wanted a password for an account of any of my users (except for 2 people), all they'd have to do is ask them, and most likely they'd get them. They don't have to steal anything to get those passwords.
Thus my systems have to take that into account, and that is an architectural problem, not a problem of encryption, so I don't need to find flaws in any encryption mechanisms, that's a theoretical problem, I need to solve practical ones, and that is a third reason you are a snake oil salesman.
Why would you expect Free Market to fix a problem for you, when you don't let it work?
The way that airlines are regulated/subsidized/treated by the government, it's a surprise there is any competition at all, forget about fixing minor issues like this one.
Your attitude towards Free Market is misdirected, you should be directing that at the government.
Right, that's why I am running OpenBSD, using open SSL, hashing the passwords. --
I know types like you, whenever you see a project you must force it to be exactly like the model you have in your head, any deviation from your model is obviously wrong, no matter how useless and redundant the stuff is.
More importantly, you are the kind of guy who is impossible to convince of anything and you believe that anybody not seeing it your way is wrong. You would force any project into a specific pattern, you'd force any project into frameworks you personally approve of, anything else is absolutely intolerable for you. Anything that does not correspond to your view is wrong.
You know, I have seen enough of this. If you were serious, you'd display a modicum of common sense and would admit the simple truth:
1. If anyone has my database table with the hashes of the passwords, then they would have the salt data right in front of them. 2. If they have the hashes and they have the salt in front of them, then it is exactly the same if the hashes were of actual passwords without any salt on them in the first place.
It's either that or
3. If I am storing salt so secure that nobody can get them, then I am storing hashes so secure that nobody can get them.
-- So storing salt is as secure as storing hashes of passwords. If storing hashes of passwords is insecure, then storing salt is insecure. --
Given all of that, it only means this: either don't bother with salt at all, because the hashes are stored so secure that nobody can get them and there is no problem and salt is pointless OR do not store salt, only store hashes because obviously this data can be somehow retrieved.
Given these choices, I chose to store hashes only and to load salt once and remove it from the system so nobody has it except for me and it is physically impossible to get from the servers / systems / company actually.
If given all of these conditions, you still insist that your way is more secure - you are a snake oil salesman and I personally prefer not to deal with you in business.
People like that are recognizable easily by pushing forward ideas that are so contradictory and really pointless and often expensive and in reality add nothing of value at all.
Finally, here is a piece of real world, it's funny how xkcd gets this stuff so right and you don't, except that we know that our users share their passwords and generally do not care much about security of these passwords, thus relying on passwords for security would be totally insane, that's another reason why I see you the way I see you.
Oh, and you still are repeating the same idiocy as everybody else here saying that storing salt with hashed passwords is more secure than not.
Can you count numbers? Count this: what's the difference between knowing the hash value of a password without salt and knowing hash value of a password that has salt AND knowing the salt? Do that math, you'll figure it out eventually that there those values are the same.
You are wrong when you simply pile every possible application in the world into the same category.
Beside which, you are wrong about my assumptions: I assume that my application users come up with passwords that are weak or that they by mistake/any other reason give their passwords away or simply are not careful and somebody reads their password.
You are wrong when you think that password is more difficult to steal from a user than it is from any system/backup/whatever, you are demonstrating a flaw in thinking insisting that password itself is secure.
I don't assume any of that, in fact I assume my users share their passwords because I know that they do and I can't do much about that. So instead of relying on weak ass assumptions about security of application passwords, I assume the worst and do more important stuff to secure the application - monitoring, constant logging of data and comparing usage patterns. The application prevents most users (except for 4 people) to access it from outside of the office, so then it also becomes a physical security issue - who has access to our office. We look at anomalies in usage with more attention than bothering with the passwords themselves, because we KNOW that passwords are not safe.
The entire exercise is a ruse, if someone has already access to my database, they'll get the information they came for without cracking the passwords, so that's a bunch of crap.
But more to the point: storing salt in the database with the user name and the hashed password reduces the complexity of the attack, it does not increase the complexity. You have access to my database, then you can get my source probably as well, then you'll know exactly what to do with the salt you just found, how to append it or XOR it or pre-pend it, or mix it with the rest of the password and now you are just attacking the password itself without the salt.
My system is more secure by not storing the salt anywhere on the servers, but I don't even care about somebody's password stolen to this app because we monitor usage and restrict IP addresses. I am more concerned with somebody being able to directly access the database server/app server, so that's my primary concern.
I don't who you are, you got this thing into your head that there is only one way to do salt: random number/string stored together with the hashed password. But you can only use salt to attack HASHED passwords, so you got the access to my database then and I should be worried about you cracking a password? This is nonsense.
AND my way is more secure: I put the file with initialization settings onto the system before starting the application and then I kill the file after the app is running. Now to get the salt you have to not only be able to access the database, you have to get into the RAM of the server somehow, good luck with that.
When you say: YOU MUST have a random salt per account, I tell you: you are stuck in your head.
As to the hashing algorithm, that I agree, MD5 is not good in itself, but that's not what I am basing the security on.
Dude, I am storing hashed passwords. MD5 may not be the best hash algorithm, but I don't care, if you got that far as to read my database and get the encrypted passwords, then I have problems much bigger than you finding out what the passwords are.
Where did you get the idea that I am storing encrypted passwords, which part of this thread told you that, the multiple commentators who didn't see some of the thread where I posted the code for hashing the passwords? Check it out.
As to what is more secure, storing salt in the database for each password or having one salt that is loaded during the application start-up and then removing the file so that it does not exist on the system, here is my answer to that.
The only thing that salt does (try following this) is prevent an attacker who already has the ENCRYPTED passwords in his hands. It does nothing to make actual passwords more secure.
Here is the use-case I:
1. Application user A has a password: stupid-password-1 2. Application adds salt to it (in this case same salt for all passwords): stupid-password-1-yy3RD4% 3. Application hashes the password and converts it to Base64: YmJmN2IwNWY0OTkwNDUwNmNjZDY4NjdmY2FhMDE0Yzk= 4. Application stores the password in the database, but salt is NOT stored in the database.
5. Attacker X wants to break into the application by brute forcing the password, so he uses dictionary attack (never mind that in my case he won't access the app due to the firewall only letting certain IP addresses, but let's say the attacker is on one of the allowed IP addresses.) 6. Attacker X spends enough time to brute-force/dictionary attack this password: stupid-password-1 and he is in the application. Attacker X is in the application and he does not need the salt.
7. Attacker Y got access to my database and he read the encrypted passwords and now he wants to know what they are, so he runs a brute-force/dictionary attack on them, but he does NOT have the salt, so he can't use that to reduce the complexity, so his attack is unlikely to succeed. Attacker Y got access to my database. What does he need the passwords for? He already has the data that is stored there anyway.
----
Use case II:
1. Application user A has a password: stupid-password-1 2. Application adds RANDOM salt to it: stupid-password-1-yy3RD4% 3. Application hashes the password and converts it to Base64: YmJmN2IwNWY0OTkwNDUwNmNjZDY4NjdmY2FhMDE0Yzk= 4. Application stores the password in the database in the user table, the salt is also stored there.
This changes nothing for attacker X.
For attacker Y the life is simpler now, if he already has the database table, he probably even has the source code to look at (why would he have access to the database but not to the application?) Now his attack is against passwords and a known way to apply KNOWN salt to those passwords, and humans are not very good at creating truly random passwords, thus he is very likely to succeed breaking at least some of the passwords.
--
Yeah, people who believe that them storing a random salt alongside the hashed password is more secure, they are the confused ones.
As I replied in this thread a few times, my way is more secure than yours.
There is no one right way to do this, and I don't believe your way is better, here is why:
The salt only helps to slow down or make it impractical to try and attack the encrypted passwords, this means someone got their hands on those encrypted passwords. If they did that, that means that read my database. If I stored the salt for each password in my database, then they have the hash and the salt, much good does that do to slow down their attack, it makes their attack more likely to succeed.
On the other hand if they know the salt but have no access to my database, then they can't use salt for anything (specifically to 'decrypt' passwords by dictionary or brute force analysis.)
If they have access to my database, my problems are much worse than someone having a password.
The single salt I use works better, because it is not in the servers, it is physically set and removed after the application starts and reads file with settings.
What's funny is how many comment in this thread that salt should be all different for each password and stored with password information, they comment on this without understanding the purpose of salt at all.
Salt is only useful to protect the encrypted passwords, so if someone got the database and wants to decrypt the passwords. If salt is stored there as well, then how does that make it less difficult to decrypt the password? It makes it easier than what I do: store salt separately in a file and keep the file safe physically outside of the systems.
Salt is like the least useful feature out of all other security features in a system, it helps if someone stole your database, but if that happened in the first place, you have a more serious security breach.
Yes, but the point is (and I replied below to another AC) is that to be able to USE salt you have to be at the code level, you can't use it at the level of an outside intruder without having access to the installed code.
If you are that deep, in the code in the app server, then you have access to the database server anyway, and if salt was stored in the database, you could then just read it.
This is stupid and less secure than reading salt from a file during application start up and then removing the file and physically protecting it. You think there is only one way to use salt securely, that's because you don't understand how it would have to be used actually to form an attack.
If 'attacker' got the file with the salt (a physically secured file, that is not stored on the network and that only one admin has) then this attacker is way beyond our normal security procedures.
Salt is USELESS by itself and if attacker got a useful way to use it, it means he is in the app at the code level. If he is that deep, he just as well would be able to see the salt if that was stored in the database, so this entire exercise is stupid.
You either have nothing or you have everything.
If you have the salt, it means you need to be able to use it. The only way to use it is by modifying the production code. If you are that deep, you have access to the database and you'd be able to read the salt from the database if it was stored there.
My way of providing salt at the start of the application and then removing the file is MORE SECURE!
True, it is the same for everybody, and that is the only way to keep the passwords stored in the database without having to decode them to compare to the passwords from the sign on screen. You suggest different salt for every different password, then every salt has to be stored as well, it makes no sense.
However you are wrong, it does matter where the salt comes from. It comes from a file that exists only during the start-up of the application and then it disappears.
all sorts of things are possible, but what good would/etc/shadow file do, they'd have to have physical access to that database, which is not on the Internet, besides which,/etc/shadow has nothing to do with the application passwords stored in the database.
My constants files are the same always, they have defaults but also search for a specific file on the file system and overwrite itself with that data by reflection (just because it was fun to do).
And you have deducted what the constants file looks like? Try guess.
It has defaults, but the defaults are overloaded during the start-up of the application from a property file. The property file is placed into the file system and after the start of the application, it is removed from the file system. What is inside the property file obviously is more interesting, thus it is secured physically.
1. That's salt, I am obviously not showing to you how this is formed.
2. MD5 is fine here, there is no security problem with MD5 and the salt that's really different from other hash algorithms.
3. My system has other measures, settings for who is allowed to work from the outside and who is only allowed to work inside the office, only the top management is allowed to work from the outside. Everybody in the office has an account, the difference is in privileges, some people are allowed to modify certain data, some are not.
4. The firewall settings only allow specific IP addresses to connect from the outside.
Oh, it obviously returns the result, I cut that out and cut out some test code and added the closing brace by hand here rather than copying all the code.
Slashdot Mirror
Once again you are avoiding to answer this simple question, because you know there lies the truth and you can't have it.
Why is storing a hash of a password less secure than storing a hash of a password and storing a salt for it?
Don't answer, you can't, you are programmed not to be able to answer this, in the face of the obvious inconsistency you shy away from thinking about it falling onto a pre-programmed reaction.
It is also funny how you believe that this specific issue is going to lead to my systems 'getting owned' without knowing anything about my systems. Thus another pre-programmed reaction, which is also nonsense and it leads me to conclude that you are useless and I wouldn't have you anywhere near my systems.
I kid you not, I was in a in Germany store about 2 months ago, there was a bunch of tourists, a couple came to a meat counter and the guy said: "I would like 100 kilograms" of some sausage. The woman at the counter looked funny at him and I intervened knowing how punctual the Germans sometimes are.
Right, at 3 months she was yelling so loud, some people left the room. At 6 months she really yelled less.
However consider that an injection into the leg muscles of 2 full syringes with 6 vaccines at once is truly painful even for an adult, why should a 3 or 6 months old suck it up?
I agree.
Passwords are useless in the first place, and that is what you can't understand. If I relied on passwords for security, I wouldn't have any security at all. My users don't care about passwords so I can't rely on them to keep them secret because they don't.
Thus the argument that I have to invest more time into a password protecting mechanism is stupid and someone making it to me is a snake oil salesman. Twice so, for insisting that storing hashes cannot be secure but storing salt is.
If anybody wanted a password for an account of any of my users (except for 2 people), all they'd have to do is ask them, and most likely they'd get them. They don't have to steal anything to get those passwords.
Thus my systems have to take that into account, and that is an architectural problem, not a problem of encryption, so I don't need to find flaws in any encryption mechanisms, that's a theoretical problem, I need to solve practical ones, and that is a third reason you are a snake oil salesman.
Why would you expect Free Market to fix a problem for you, when you don't let it work?
The way that airlines are regulated/subsidized/treated by the government, it's a surprise there is any competition at all, forget about fixing minor issues like this one.
Your attitude towards Free Market is misdirected, you should be directing that at the government.
Right, that's why I am running OpenBSD, using open SSL, hashing the passwords.
--
I know types like you, whenever you see a project you must force it to be exactly like the model you have in your head, any deviation from your model is obviously wrong, no matter how useless and redundant the stuff is.
More importantly, you are the kind of guy who is impossible to convince of anything and you believe that anybody not seeing it your way is wrong. You would force any project into a specific pattern, you'd force any project into frameworks you personally approve of, anything else is absolutely intolerable for you. Anything that does not correspond to your view is wrong.
You know, I have seen enough of this. If you were serious, you'd display a modicum of common sense and would admit the simple truth:
1. If anyone has my database table with the hashes of the passwords, then they would have the salt data right in front of them.
2. If they have the hashes and they have the salt in front of them, then it is exactly the same if the hashes were of actual passwords without any salt on them in the first place.
It's either that or
3. If I am storing salt so secure that nobody can get them, then I am storing hashes so secure that nobody can get them.
--
So storing salt is as secure as storing hashes of passwords.
If storing hashes of passwords is insecure, then storing salt is insecure.
--
Given all of that, it only means this: either don't bother with salt at all, because the hashes are stored so secure that nobody can get them and there is no problem and salt is pointless OR do not store salt, only store hashes because obviously this data can be somehow retrieved.
Given these choices, I chose to store hashes only and to load salt once and remove it from the system so nobody has it except for me and it is physically impossible to get from the servers / systems / company actually.
If given all of these conditions, you still insist that your way is more secure - you are a snake oil salesman and I personally prefer not to deal with you in business.
People like that are recognizable easily by pushing forward ideas that are so contradictory and really pointless and often expensive and in reality add nothing of value at all.
Finally, here is a piece of real world, it's funny how xkcd gets this stuff so right and you don't, except that we know that our users share their passwords and generally do not care much about security of these passwords, thus relying on passwords for security would be totally insane, that's another reason why I see you the way I see you.
You are a snake oil salesman who stairs at the obvious truth and refuses to admit being wrong and you are projecting this trait onto me.
Count the numbers, you know, digits 1 to many.
Good day.
Oh, and you still are repeating the same idiocy as everybody else here saying that storing salt with hashed passwords is more secure than not.
Can you count numbers? Count this: what's the difference between knowing the hash value of a password without salt and knowing hash value of a password that has salt AND knowing the salt? Do that math, you'll figure it out eventually that there those values are the same.
You are wrong when you simply pile every possible application in the world into the same category.
Beside which, you are wrong about my assumptions: I assume that my application users come up with passwords that are weak or that they by mistake/any other reason give their passwords away or simply are not careful and somebody reads their password.
You are wrong when you think that password is more difficult to steal from a user than it is from any system/backup/whatever, you are demonstrating a flaw in thinking insisting that password itself is secure.
I don't assume any of that, in fact I assume my users share their passwords because I know that they do and I can't do much about that. So instead of relying on weak ass assumptions about security of application passwords, I assume the worst and do more important stuff to secure the application - monitoring, constant logging of data and comparing usage patterns. The application prevents most users (except for 4 people) to access it from outside of the office, so then it also becomes a physical security issue - who has access to our office. We look at anomalies in usage with more attention than bothering with the passwords themselves, because we KNOW that passwords are not safe.
Cheers to your high-tower there.
The entire exercise is a ruse, if someone has already access to my database, they'll get the information they came for without cracking the passwords, so that's a bunch of crap.
But more to the point: storing salt in the database with the user name and the hashed password reduces the complexity of the attack, it does not increase the complexity. You have access to my database, then you can get my source probably as well, then you'll know exactly what to do with the salt you just found, how to append it or XOR it or pre-pend it, or mix it with the rest of the password and now you are just attacking the password itself without the salt.
My system is more secure by not storing the salt anywhere on the servers, but I don't even care about somebody's password stolen to this app because we monitor usage and restrict IP addresses. I am more concerned with somebody being able to directly access the database server/app server, so that's my primary concern.
I don't who you are, you got this thing into your head that there is only one way to do salt: random number/string stored together with the hashed password. But you can only use salt to attack HASHED passwords, so you got the access to my database then and I should be worried about you cracking a password? This is nonsense.
AND my way is more secure: I put the file with initialization settings onto the system before starting the application and then I kill the file after the app is running. Now to get the salt you have to not only be able to access the database, you have to get into the RAM of the server somehow, good luck with that.
When you say: YOU MUST have a random salt per account, I tell you: you are stuck in your head.
As to the hashing algorithm, that I agree, MD5 is not good in itself, but that's not what I am basing the security on.
Dude, I am storing hashed passwords. MD5 may not be the best hash algorithm, but I don't care, if you got that far as to read my database and get the encrypted passwords, then I have problems much bigger than you finding out what the passwords are.
Where did you get the idea that I am storing encrypted passwords, which part of this thread told you that, the multiple commentators who didn't see some of the thread where I posted the code for hashing the passwords? Check it out.
As to what is more secure, storing salt in the database for each password or having one salt that is loaded during the application start-up and then removing the file so that it does not exist on the system, here is my answer to that.
Read the entire thread before answering, ok?
I am confused? :)
The only thing that salt does (try following this) is prevent an attacker who already has the ENCRYPTED passwords in his hands. It does nothing to make actual passwords more secure.
Here is the use-case I:
1. Application user A has a password: stupid-password-1
2. Application adds salt to it (in this case same salt for all passwords): stupid-password-1-yy3RD4%
3. Application hashes the password and converts it to Base64: YmJmN2IwNWY0OTkwNDUwNmNjZDY4NjdmY2FhMDE0Yzk=
4. Application stores the password in the database, but salt is NOT stored in the database.
5. Attacker X wants to break into the application by brute forcing the password, so he uses dictionary attack (never mind that in my case he won't access the app due to the firewall only letting certain IP addresses, but let's say the attacker is on one of the allowed IP addresses.)
6. Attacker X spends enough time to brute-force/dictionary attack this password: stupid-password-1 and he is in the application.
Attacker X is in the application and he does not need the salt.
7. Attacker Y got access to my database and he read the encrypted passwords and now he wants to know what they are, so he runs a brute-force/dictionary attack on them, but he does NOT have the salt, so he can't use that to reduce the complexity, so his attack is unlikely to succeed.
Attacker Y got access to my database. What does he need the passwords for? He already has the data that is stored there anyway.
----
Use case II:
1. Application user A has a password: stupid-password-1
2. Application adds RANDOM salt to it: stupid-password-1-yy3RD4%
3. Application hashes the password and converts it to Base64: YmJmN2IwNWY0OTkwNDUwNmNjZDY4NjdmY2FhMDE0Yzk=
4. Application stores the password in the database in the user table, the salt is also stored there.
This changes nothing for attacker X.
For attacker Y the life is simpler now, if he already has the database table, he probably even has the source code to look at (why would he have access to the database but not to the application?) Now his attack is against passwords and a known way to apply KNOWN salt to those passwords, and humans are not very good at creating truly random passwords, thus he is very likely to succeed breaking at least some of the passwords.
--
Yeah, people who believe that them storing a random salt alongside the hashed password is more secure, they are the confused ones.
As I replied in this thread a few times, my way is more secure than yours.
There is no one right way to do this, and I don't believe your way is better, here is why:
The salt only helps to slow down or make it impractical to try and attack the encrypted passwords, this means someone got their hands on those encrypted passwords. If they did that, that means that read my database. If I stored the salt for each password in my database, then they have the hash and the salt, much good does that do to slow down their attack, it makes their attack more likely to succeed.
On the other hand if they know the salt but have no access to my database, then they can't use salt for anything (specifically to 'decrypt' passwords by dictionary or brute force analysis.)
If they have access to my database, my problems are much worse than someone having a password.
The single salt I use works better, because it is not in the servers, it is physically set and removed after the application starts and reads file with settings.
What's funny is how many comment in this thread that salt should be all different for each password and stored with password information, they comment on this without understanding the purpose of salt at all.
Salt is only useful to protect the encrypted passwords, so if someone got the database and wants to decrypt the passwords. If salt is stored there as well, then how does that make it less difficult to decrypt the password? It makes it easier than what I do: store salt separately in a file and keep the file safe physically outside of the systems.
Salt is like the least useful feature out of all other security features in a system, it helps if someone stole your database, but if that happened in the first place, you have a more serious security breach.
Yes, but the point is (and I replied below to another AC) is that to be able to USE salt you have to be at the code level, you can't use it at the level of an outside intruder without having access to the installed code.
If you are that deep, in the code in the app server, then you have access to the database server anyway, and if salt was stored in the database, you could then just read it.
This is stupid and less secure than reading salt from a file during application start up and then removing the file and physically protecting it. You think there is only one way to use salt securely, that's because you don't understand how it would have to be used actually to form an attack.
If 'attacker' got the file with the salt (a physically secured file, that is not stored on the network and that only one admin has) then this attacker is way beyond our normal security procedures.
Salt is USELESS by itself and if attacker got a useful way to use it, it means he is in the app at the code level. If he is that deep, he just as well would be able to see the salt if that was stored in the database, so this entire exercise is stupid.
You either have nothing or you have everything.
If you have the salt, it means you need to be able to use it. The only way to use it is by modifying the production code. If you are that deep, you have access to the database and you'd be able to read the salt from the database if it was stored there.
My way of providing salt at the start of the application and then removing the file is MORE SECURE!
The more I know people, the more I am happy to qualify as a dog.
True, it is the same for everybody, and that is the only way to keep the passwords stored in the database without having to decode them to compare to the passwords from the sign on screen. You suggest different salt for every different password, then every salt has to be stored as well, it makes no sense.
However you are wrong, it does matter where the salt comes from. It comes from a file that exists only during the start-up of the application and then it disappears.
all sorts of things are possible, but what good would /etc/shadow file do, they'd have to have physical access to that database, which is not on the Internet, besides which, /etc/shadow has nothing to do with the application passwords stored in the database.
I obviously meant 'deduced' not deducted.
My constants files are the same always, they have defaults but also search for a specific file on the file system and overwrite itself with that data by reflection (just because it was fun to do).
And you have deducted what the constants file looks like?
Try guess.
It has defaults, but the defaults are overloaded during the start-up of the application from a property file. The property file is placed into the file system and after the start of the application, it is removed from the file system. What is inside the property file obviously is more interesting, thus it is secured physically.
1. That's salt, I am obviously not showing to you how this is formed.
2. MD5 is fine here, there is no security problem with MD5 and the salt that's really different from other hash algorithms.
3. My system has other measures, settings for who is allowed to work from the outside and who is only allowed to work inside the office, only the top management is allowed to work from the outside. Everybody in the office has an account, the difference is in privileges, some people are allowed to modify certain data, some are not.
4. The firewall settings only allow specific IP addresses to connect from the outside.
Oh, it obviously returns the result, I cut that out and cut out some test code and added the closing brace by hand here rather than copying all the code.