Tag Info

New answers tagged

0

Nothing is futile, and there are no silver bullets. Everything depends. There was a sidebar about using disk encryption. That is protecting against a different attack surface, so lets ignore it. The question asks if it makes sense to encrypt data that is in a database, under the assumption that it needs to be plaintext for a web client. The presented ...


1

It depends on from which threats are you going to protect. Encrypting data on database level is great protection, when you have so many IT employees, that you're able to divite them into teams responsible for each layer. For example, banks and credit cards acquirers use PCI DSS security standard, which require such protection along with dividing IT staff ...


1

To answer your question according to the points: 1) In a pure sense, no. PHI means identifiable patient information (e.g. a name, an address, a social security number, etc) combined with clinical data (e.g. a diagnosis, CPT code, test result etc). A foreign key in and of itself is not PHI. 2) Not that I am aware of for HIPAA -- HIPAA is more of general ...


0

Disclaimer: I only have a baseline understanding of HIPAA. I would think that as long as the encrypted data is not accessible in an unencrypted form, through the foreign key then it's acceptable. Provided your foreign key is an ID of some sort that's unrelated to the specific PHI the key would not need to be encrypted.


0

Depends..... For example bank store PINs in their own database, on their own server. The server also auto deletes the data if anyone tries to remove it from the rack. One good reason for a separate database is if you wish to be able to get your customers to send you there database when they hit a bug. If the database does not contain any password ...


1

The traditional way to avoid the user having to type in a user name is to include "remember me" functionality where the user name is persisted in a manner that is associated with the browser, e.g. an encrypted cookie or a cookie containing a durable token (say, 30 days) that the server can use to infer the user name. Some of the replies here are going to ...


1

Another problem that I see here that's also related to security: suppose one of your users has to change their password because they were infected with a keylogger or a phishing attack. How will you manage to do that? The only way you can is by asking them for their password, rehashing that password, then replacing it in your code, recompiling and then ...


4

That is actually far less secure. In an ideal world, where your database is not sitting in the DMZ but is instead only accessible directly from your web server, and then with limited account rights, in order to breach your database and retrieve your hashed password table, I have to: Expose your software database connection variables (account/password) by ...


26

A few points: What you mean with encrypting passwords in the DB is hashing. That´s a big big difference. The first reason why DBs are used instead of hard coding user data is not security, but simplicity (add/modify/delete users without recompiling etc.) Storing passwords in plaintext is a problem, doesn't matter if they are in your program or in the ...


10

Please, do not Hard Code credentials or hashes. Hardcoded passwords may compromise system security in a way that cannot be easily remedied. [...] it also makes fixing the problem extremely difficult. See OWASP page about Hard Coded Passwords [...]many hashes are reversible (or at least vulnerable to brute force attacks) - and further, many ...


5

This is usually a combination of luck, technology and hand waving. You may see that your database server was hacked (via unusual activity for instance, gigabytes being transferred to Internet, a fact detected by, say, your network provider). You may then have logs which trace activity on the database (ranging from "someone accessed the DB" to actual ...


5

No, that doesn't guarantee overwriting. If sparse files are enabled for your filesystem, long strings of zeroes might not actually be written out. Also, the area used by the filesystem to keep track of files (inode table or other nomenclature depending on the filesystem) probably wont' be filled and behavior varies greatly based on the filesystem you're ...


0

If your threat model means your code has to run on a computer you can't trust, there is no way to protect your data: it simply isn't possible. No matter what you do, the decryption key MUST be present in the memory of the system performing the decryption in order to access the data. This means that the only possible way to protect the key is to move that ...



Top 50 recent answers are included