This Tuesday! Learn key insights about modern cyber protection services & gain practical strategies to skyrocket business:
- What it takes to build a cloud service portfolio
- How to determine which services will help your unique business grow
- Various use-cases and examples
Encrypting passwords – What’s the point?
It’s Friday, I’ve had a long week and something has just popped into my head that I really should be able to answer, but I can’t! It’s probably a very stupid question.
You have a finance or HR system in your business, perhaps based on an Oracle or SQL database. A decision is made, like most places I presume, not to encrypt the entire database, however users passwords are stored encrypted (in whatever way that may be). What’s the point behind this? What I’m questioning is if an attacker can get access to that database file can they not get access to all the other data they need and there for not require all the passwords?
Perhaps what I’m missing is a better understanding of how an attack may happen on a database or how databases work. The only thing I can think of is that an SQL/Oracle etc. database isn’t a flat file so you can’t just open it in a notepad and view data. You will have to load/connect to it via an SQL Server where you will have to authenticate. Then what? You manage to compromise/guess an account username and password. This gives you access to the database and therefore the data you want. You’ve got access so why do you need the remaining passwords? What’s so valuable about the passwords when the system may hold bank account details that may not be encrypted?
One of the only uses I can think of is you compromise an account in the database so you can view data but what are you going to do with it. Isn’t the point you then compromise other accounts so that you can log into the databases application and run fraudulent transactions through the system?
You have a finance or HR system in your business, perhaps based on an Oracle or SQL database. A decision is made, like most places I presume, not to encrypt the entire database, however users passwords are stored encrypted (in whatever way that may be). What’s the point behind this? What I’m questioning is if an attacker can get access to that database file can they not get access to all the other data they need and there for not require all the passwords?
Perhaps what I’m missing is a better understanding of how an attack may happen on a database or how databases work. The only thing I can think of is that an SQL/Oracle etc. database isn’t a flat file so you can’t just open it in a notepad and view data. You will have to load/connect to it via an SQL Server where you will have to authenticate. Then what? You manage to compromise/guess an account username and password. This gives you access to the database and therefore the data you want. You’ve got access so why do you need the remaining passwords? What’s so valuable about the passwords when the system may hold bank account details that may not be encrypted?
One of the only uses I can think of is you compromise an account in the database so you can view data but what are you going to do with it. Isn’t the point you then compromise other accounts so that you can log into the databases application and run fraudulent transactions through the system?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Humans are lazy (I know I am human!). People tends to reuse the same password over and over again. So if your password are clear text and a cyber-attacker grabs them, chances are they will be able to connect to other service from the web for those users.
If you are using Passwords in DB then it is a very good idea to encrypt then so that other people cannot login in to the Db and see your password. People can also misuse your password as they can see that as a clear text. So it is very good and necessary thing.
Apart from this people also encrypt Salary and other important information.
Good luck
Apart from this people also encrypt Salary and other important information.
Good luck
Also it is usually a good idea to use a one way encryption algorithm on passwords. Since lots of users tend to reuse passwords this adds an extra layer of security to a user. There is really know reason for an application to ever know the actual password. Just if the two encryptions match.
Several different ways of data encryption exist... and even SQL database can be open in Notepad... and no 100% secure way of encryption exists...
If the database is stored on the local computer like SQL Express or Oracle Express or MS Access etc. then users do have 100% time for hacking attempts.
If the database is stored on a server then the possibility of some attack is lower but still exists. The easiest way is to become an admin on such server and then you may do almost anything.
If the database is stored on a server and sensitive data are encrypted then depends on the encryption way how easy is to decode the encrypted data.
If you use password for data access and decrypt the data when correct password is provided then the easiest way is to ask people for the password. And believe or not the stupidity is everywhere... Here cannot help "one way encryption" here can help just the power off button.
So the solution is to make the data access and data readability difficult for human. But programmers are not human...
To be more specific you should do following:
- Do not store passwords but just password hashes (= "one way encryption"). This is for practical reasons as nobody from outside can read all the passwords at the first view. Of course, you can try to hack these hashes and if they were created from simple passwords then you may reverse them easily.
- So this results in: Use Password Managers wherever possible
- Other sensitive info should be hidden by symmetric or asymmetric encryption. Symmetric encryption allows data searching, asymmetrically encrypted data is impossible to search via SQL commands.
- If the data should not be readable by admins then you have to use encryption where the key is stored on the dedicated end-user computer only... a lot of overhead... and 100% data lost when you loose the key...
and we would continue...
If the database is stored on the local computer like SQL Express or Oracle Express or MS Access etc. then users do have 100% time for hacking attempts.
If the database is stored on a server then the possibility of some attack is lower but still exists. The easiest way is to become an admin on such server and then you may do almost anything.
If the database is stored on a server and sensitive data are encrypted then depends on the encryption way how easy is to decode the encrypted data.
If you use password for data access and decrypt the data when correct password is provided then the easiest way is to ask people for the password. And believe or not the stupidity is everywhere... Here cannot help "one way encryption" here can help just the power off button.
So the solution is to make the data access and data readability difficult for human. But programmers are not human...
To be more specific you should do following:
- Do not store passwords but just password hashes (= "one way encryption"). This is for practical reasons as nobody from outside can read all the passwords at the first view. Of course, you can try to hack these hashes and if they were created from simple passwords then you may reverse them easily.
- So this results in: Use Password Managers wherever possible
- Other sensitive info should be hidden by symmetric or asymmetric encryption. Symmetric encryption allows data searching, asymmetrically encrypted data is impossible to search via SQL commands.
- If the data should not be readable by admins then you have to use encryption where the key is stored on the dedicated end-user computer only... a lot of overhead... and 100% data lost when you loose the key...
and we would continue...
If an attacker can get access to the database.....
There are several levels of access.
Grabbing the DB files may pose problems if the db has passwords. Not insurmountable though and it it isn't just the physical security of the server that you have to watch, you need to secure backups too.
compromise the local machine and load the database management tools such as SSMS and they bay just connect with the current user account. bingo passwords compromised
SQL injection on a web app could allow someone to dump passwords.
SQL injection on a client app is just as easy. Set up a SQL proxy and you can intercept the connection and send your own commands
If you compromise a host on the network, you can connect on 1433 with a SQL client of choice and run SQL commands to extract the passwords.
Short answer - password encryption is a vital layer of security.
There are several levels of access.
Grabbing the DB files may pose problems if the db has passwords. Not insurmountable though and it it isn't just the physical security of the server that you have to watch, you need to secure backups too.
compromise the local machine and load the database management tools such as SSMS and they bay just connect with the current user account. bingo passwords compromised
SQL injection on a web app could allow someone to dump passwords.
SQL injection on a client app is just as easy. Set up a SQL proxy and you can intercept the connection and send your own commands
If you compromise a host on the network, you can connect on 1433 with a SQL client of choice and run SQL commands to extract the passwords.
Short answer - password encryption is a vital layer of security.
I think the confusion starts in the understanding of what the purpose of db encryption.
The db encryption deals with securing the data from being taken. Direct access to the server, is needed.
I.e. Boot system using alternate boot media, locate the database files, copy them out.
Attach them on another server...... If encrypted, this type person will not have access to the db data without the master key/certificate.
Several explained why user passwords are encrypted.
One of them is a way to avoid having an inside person accessing and disclosing other user's credentials.
I.e. Person A has rights to manage access the data, list the user/password. Either use other's credentials todo .... Or sale ..
...
The db encryption deals with securing the data from being taken. Direct access to the server, is needed.
I.e. Boot system using alternate boot media, locate the database files, copy them out.
Attach them on another server...... If encrypted, this type person will not have access to the db data without the master key/certificate.
Several explained why user passwords are encrypted.
One of them is a way to avoid having an inside person accessing and disclosing other user's credentials.
I.e. Person A has rights to manage access the data, list the user/password. Either use other's credentials todo .... Or sale ..
...
I don't think the question was bout database encryption, merely the encryption of the contents of the password (and maybe username) columns
Yes, the asker pondered the significance if one chooses not to encrypt the database, why encrypt the user passwords.
i.e. "Subject: Encrypting passwords, what's the point?"
The password encryption is it encrypted by the SQL server, setting on a column, or is actually encrypted by the process storing the encrypted password content.
To the asker
Think of an office building, front,entry doors are not locked, the individual offices are still locked.
Converting the example into the question, what is the point of locking the offices when the front/entry doors are not locked.
mainly to Johns comment, encrypting the entire database adds complexity and overhead that might not need to be there. i.e. city, states, countries, street addresses, etc. do not need to be encrypted, personal identifiable information should. so instead of securing all, encrypting some columns with significance would provide some security.
but I doubt that is your question. since even some column encryption requires detailed planing for DR/backup...
i.e. "Subject: Encrypting passwords, what's the point?"
The password encryption is it encrypted by the SQL server, setting on a column, or is actually encrypted by the process storing the encrypted password content.
To the asker
Think of an office building, front,entry doors are not locked, the individual offices are still locked.
Converting the example into the question, what is the point of locking the offices when the front/entry doors are not locked.
mainly to Johns comment, encrypting the entire database adds complexity and overhead that might not need to be there. i.e. city, states, countries, street addresses, etc. do not need to be encrypted, personal identifiable information should. so instead of securing all, encrypting some columns with significance would provide some security.
but I doubt that is your question. since even some column encryption requires detailed planing for DR/backup...
Besides the argument of passwords used multiple times on other sites and services, too. Knowing passwords makes it easier to do anything in an account like ordering stuff on behalf of someone or making a money transaction than to put order data into a database you don't know or just changing your own account balance. When that doesn't have any transaction related data it can be detected as data manipulation, so even having full access to data you can't easily make any change undetected, besides transaction logs saving every state anyway.
Another reason is that a typical attack on a DBs is for getting at passwords. Storing strong password hashes (not encrypted passwords) makes such databases unattractive for that matter alone.
You're right about the databases of banks and other financial institutions of course not only being the goal of getting passwords, therefore I'm quite sure such data is indeed encrypted, but even if not, it's surely easier to get a believable money transfer by being able to log into some account and use it, to produce all the side data created for whatever the system does via its (web) interface.
Bye, Olaf.
Another reason is that a typical attack on a DBs is for getting at passwords. Storing strong password hashes (not encrypted passwords) makes such databases unattractive for that matter alone.
You're right about the databases of banks and other financial institutions of course not only being the goal of getting passwords, therefore I'm quite sure such data is indeed encrypted, but even if not, it's surely easier to get a believable money transfer by being able to log into some account and use it, to produce all the side data created for whatever the system does via its (web) interface.
Bye, Olaf.
Another great reason to encrypt a password in a database with a one way hash is can help protect users passwords from people who do have access to your database. It kind of protects your company from itself. You don't have to worry about a disgruntled employee or someone exporting passwords not thinking they are doing anything that could be stolen.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial