Encrypt all user data including Email-Address
Permalink
Hello
Where in the c5-Code to I have to place the encryption/decryption methods if I want to encrypt all user data including the email address??
Thanks for any hint on this!
Regards,
Daniel
Where in the c5-Code to I have to place the encryption/decryption methods if I want to encrypt all user data including the email address??
Thanks for any hint on this!
Regards,
Daniel
Any ideas on this?
Is it user data held in the database you want to encrypt?
Or do you want to encrypt when data is shown on a web page?
Or do you want to encrypt when data is shown on a web page?
Right, well just the user attributes, like email, username and also the custom user attributes, but only that.
I think it would be a good idea for you to explain why you want do this, or what you are trying to achieve by obscuring this information.
If it is for "enhanced security" then it's really not a good idea for a bunch of reasons - it's more security through obscurity.
If the data being store is being related to Social Insurance numbers, or passport numbers, or VISA numbers, then there are cases and methods to encrypt data properly. However, there are many security methods and implementations that need to be performed to protect data properly - and encrypting stored user data is only one piece of the puzzle.
Imagine building a bank with the biggest, thickest, strongest front door you could find - only to put in crappy easily breakable windows ?
If it is for "enhanced security" then it's really not a good idea for a bunch of reasons - it's more security through obscurity.
If the data being store is being related to Social Insurance numbers, or passport numbers, or VISA numbers, then there are cases and methods to encrypt data properly. However, there are many security methods and implementations that need to be performed to protect data properly - and encrypting stored user data is only one piece of the puzzle.
Imagine building a bank with the biggest, thickest, strongest front door you could find - only to put in crappy easily breakable windows ?
Hi - well I'm not an web Developer, so maybe what I'm trying is not a good idea.
What I saw is that the user data is stored basically as it is in the db. Now in case it is hacked (the db for example), i would like to not have all the user data just there.
So does encrypting the user data not help much? How high is anyway the probability that someone can accesss the user data? I'm actually a bit surprised that user data is not generally encrypted....
What I saw is that the user data is stored basically as it is in the db. Now in case it is hacked (the db for example), i would like to not have all the user data just there.
So does encrypting the user data not help much? How high is anyway the probability that someone can accesss the user data? I'm actually a bit surprised that user data is not generally encrypted....
what would be a better idea to achieve "enhanced security"?
Storing user data in the db unencrypted is typical behaviour.
If the db gets hacked, the information is stolen.
Typically the password column is the only data that is being stored encrypted with some sort of method like MD5 with some salt and (maybe) hashes.
However, when you login, the system needs to be able to decrypt the data for authentication, so there are other parameters that the systems needs to check - associated keys to the data. The keys needs to be stored securely, above the root, etc, etc, etc. So there is more than one piece of the puzzle to put the password together.
But - when you make this request over http, it is being sent in plain text, which is why you need to apply an SSL - so the request becomes encrypted over https://
The tables are not be encrypted because assorted implementations of all of this are more important :
- the level and amount of security needs to match the sensitivity of the data (you'd not build Fort Knox to protect 5 bucks)
- speed and agility of the applications and queries that need to access that data, especially when joining data (maybe User profile and Address for example)
- there are already security measures in the code and on the server that are in place before being able to reach the data
- other more obvious methods like creating a Username to login, and disallowing logging with email addresses
- ensure passwords are strong - length of a password is more important than the characters being used :https://www.grc.com/haystack.htm...
- use 2 factor login and verification
- adjusting your apache
- database user and their Grants being able to access the right tables
etc, etc, etc, etc.
I could go on and on about this subject, and it's a huge and specialized field.
This is generally not something most people want to take on on their own - which is why we use frameworks.
HTH, dave
If the db gets hacked, the information is stolen.
Typically the password column is the only data that is being stored encrypted with some sort of method like MD5 with some salt and (maybe) hashes.
However, when you login, the system needs to be able to decrypt the data for authentication, so there are other parameters that the systems needs to check - associated keys to the data. The keys needs to be stored securely, above the root, etc, etc, etc. So there is more than one piece of the puzzle to put the password together.
But - when you make this request over http, it is being sent in plain text, which is why you need to apply an SSL - so the request becomes encrypted over https://
The tables are not be encrypted because assorted implementations of all of this are more important :
- the level and amount of security needs to match the sensitivity of the data (you'd not build Fort Knox to protect 5 bucks)
- speed and agility of the applications and queries that need to access that data, especially when joining data (maybe User profile and Address for example)
- there are already security measures in the code and on the server that are in place before being able to reach the data
- other more obvious methods like creating a Username to login, and disallowing logging with email addresses
- ensure passwords are strong - length of a password is more important than the characters being used :https://www.grc.com/haystack.htm...
- use 2 factor login and verification
- adjusting your apache
- database user and their Grants being able to access the right tables
etc, etc, etc, etc.
I could go on and on about this subject, and it's a huge and specialized field.
This is generally not something most people want to take on on their own - which is why we use frameworks.
HTH, dave
Suppose user data was encrypted before saving it in the database, then decrypted as necessary when reading it from the database.
Superficially it sounds good. Anyone getting a copy of the database would not be able to read that data. The algorithms and keys for decrypting would be coded into the site, so if they could get at the database, they could get at all that as well.
As @davidinottowa says, no point having a strong door if the windows are fragile.
On the other hand, if they already had access to the site dashboard, they could simply read that data from the dashboard user page.
A few thoughts on data:
- only collect data you need
- don't keep it unless you actually need to
- make sure all passwords associated with your site, host account and ftp are strong, unique and changed regularly.
- don't leave backups in the web space, delete them as soon as they are made and downloaded.
There are also legal and institutional requirements for storing sensitive data.
If it really is necessary to your application to keep highly sensitive data, you probably need a secure server at secure location. The average rental web space just isn't secure enough.
Superficially it sounds good. Anyone getting a copy of the database would not be able to read that data. The algorithms and keys for decrypting would be coded into the site, so if they could get at the database, they could get at all that as well.
As @davidinottowa says, no point having a strong door if the windows are fragile.
On the other hand, if they already had access to the site dashboard, they could simply read that data from the dashboard user page.
A few thoughts on data:
- only collect data you need
- don't keep it unless you actually need to
- make sure all passwords associated with your site, host account and ftp are strong, unique and changed regularly.
- don't leave backups in the web space, delete them as soon as they are made and downloaded.
There are also legal and institutional requirements for storing sensitive data.
If it really is necessary to your application to keep highly sensitive data, you probably need a secure server at secure location. The average rental web space just isn't secure enough.
Well said John.
The frameworks most people use are "secure enough" for the majority.
People fall flat by their own volition by not using strong passwords that are changed regularly as you mentioned. The owner of the data needs to take responsibility.
If you *had to* store credit card numbers, and if you want to get a little mental, you could store them on separate servers and use a view with a remote join. (maybe - lol!)
I've used Verisign in the past, as once the payment processing went through, we only needed to store the transaction ID number - from their, we could issue refunds, cancellations, etc, etc. The number was transfered over https:// and never stored anywhere.
The frameworks most people use are "secure enough" for the majority.
People fall flat by their own volition by not using strong passwords that are changed regularly as you mentioned. The owner of the data needs to take responsibility.
If you *had to* store credit card numbers, and if you want to get a little mental, you could store them on separate servers and use a view with a remote join. (maybe - lol!)
I've used Verisign in the past, as once the payment processing went through, we only needed to store the transaction ID number - from their, we could issue refunds, cancellations, etc, etc. The number was transfered over https:// and never stored anywhere.
Just wondering how this all stacks up with new General Data Protection Regulations (GDPR) coming in to force in Europe, and stored personal data in Concrete5?
