I am lookin to harden security on one of my client sites. There is no payment provider set up so sensitive Direct Debit information needs to be on a mySql server. This Direct Debit information needs to be human readable by users from accounting department.
Testing server is set up as follows:
At present, main site is sitting on a wordpress blog.
Customer completes HTTPS encrypted form with an EV SSL certificate.
Data is stored in a separate database to the wordpress database.
Direct debit details are currently stored as plain text
Now part 4 is what bothers me... but it's ok at the moment, because only on the testing server!
This is really difficult to answer, as it depends on how far you need to protect this data.
First step is obviously encrypting all details stored in mysql, incase someone gets a dump of your database.
This solution is good, but it introduces the vulnerability as if someone gets the decryption keys from your application server, they would be able to decrypt the dump of the database anyway.
There are many solutions to consider from here, i'm sure with some research you should be able to find some decent ones, but one way that comes to mind is:
You could encrypt the data on the application servers with a public/private key encryption algorithm. Public key can only be used to encrypt the information for storage, which lives on your application server. If that gets hacked, the only thing that they will be able to do is to add more data to your database =/. The private key in this case will be a password that would need to be entered every time a human needs to see this information.
This has the obvious disadvantage that you can't do any machine processing on your data, as its traveling completely encrypted all the way until its displayed.
(And you still have vulnerabilities of someone gaining access to your application server and simply dumping the session files/memcache where the key would have to be stored temporarily)
To be honest, first thing i'd do is encrypt the entire database one way or another. That alone adds a decent layer of protection. Dumping the database is easier than getting access to the file system of a server in most cases.
Are you talking about bank account details / credit card details or both?
Be aware storing credit card details brings attached fulfilling PCI requirements.
Also, if you are planning to store confidential details, NEVER store them unencrypted.
Any questions, just let me know.
Fabio
#fcerullo
Related
Hello to all
I did a lot of research on encrypting important data such as credit card numbers in Spring Boot, and three ways to securely encrypt data caught my attention:
Protect secrets with Hashicorp Vault
Column-level encryption
Data Encryption with Java Cryptographic Extensions
All three methods have their advantages and disadvantages. The initial setup of the vault requires a lot of configuration, and I could not find a complete and integrated source for learning it. Column-level data encryption imposes a large processing load on the server, and requires the management of cryptographic keys. The third case requires the creation, management and maintenance of encryption keys for each client request. Is there a better choice for managing sensitive customer data such as email addresses or credit card numbers? Or is it recommended to use Vault to manage the secrets of website users?
Can I encourage you to take a look at our product. I don't want this to be a shameless plug but as a developer who has felt your pain, I think you would want to take a look at what we have. We have designed it to address some of your concerns. ubiqsecurity.com.
To address your specific considerations.
MUCH easier than setting up Hashicorp Vault. We have demos of creating an account and sharing encrypted data in two different languages within 5 minutes. The demos should help you get started if necessary but I wouldn't expect you to need them. Our client libraries also have fully functional examples to help you get started.
This seems to be the reason DBAs are hesitant to turn on encryption within the DB layer. We are leaving the encryption at the application layer. If your encrypted DB is up and running and someone is on the DB server with harvested credentials is your DB really secure?
We manage encryption keys for you. Client uses an API key (similar to other SaaS). Data is encrypted on the client.
Please feel free to reach out to us if you have any questions. Again, not trying to be a shameless plug, but we know the problems developers face when working with encryption and feel our solution addresses a number of the issues you are facing as well as others you haven't even mentioned.
Are there any examples of using encryption to encrypt the disk-cache used by OkHttp's HttpResponseCache? Naively, I don't think this is a very hard thing to do, but I'd appreciate any advice or experience to avoid security-pitfalls.
Without too many specifics, here's what I'm trying to achieve: a server that accept user's api-keys (typically 40-character random string) for established service X, and makes many API calls on the users behalf. The server won't persist user's api-keys, but a likely use case is that users will periodically call the server, supplying the api-key each time. Established service X uses reasonable rate-limiting, but supports conditional (ETag, If-Modified-Since) requests, so server-side caching by my server makes sense. The information is private though, and the server will be hosted on Heroku or the like, so I'd like to encrypt the files cached by HttpResponseCache so that if the machine is compromised, they don't yield any information.
My plan would be to create a wrapper around HttpResponseCache that accepts a secret key - which would actually be a hash of half of the api-key string. This would be used to AES-encrypt the cached contents and keys used by HttpResponseCache. Does that sound reasonable?
Very difficult to do with the existing cache code. It's a journaled on-disk datastructure that is not designed to support privacy, and privacy is not a feature you can add on top.
One option is to mount an encrypted disk image and put the cache in there. Similar to Mac OS X's FileVault for example. If you can figure out how to do that, you're golden.
Your other option is to implement your own cache, using the existing cache as a guide. Fair warning: the OkResponseCache is subject to change in the next release!
I'm building an app for which I need to store my users' login credentials for a 3rd party service. Communication with the 3rd party service is done via https GET requests.
From what I've seen, looking at posts like this one, there's no clear answer as to the best practices for doing this, and the specific methods discussed in that post at least all leave something to be desired.
So one thought I had was that perhaps it'd be possible to get around the problem by "pre-encrypting" the query string for the 3rd party request and storing that encrypted data in my db in lieu of storing the users' credentials directly. This way I can store the credentials in an encrypted form but not worry about the key being compromised, as it's held by the 3rd party, not me. And if my db were compromised the intruder wouldn't get anything more than he could obtain by packet sniffing.
I can't seem to find any examples of anyone doing something like this, so I'd like feedback on whether the community thinks it's a reasonable approach. Beyond that, a little help on how exactly to do it would be great. I'm building my app in node.js/express, and currently I'm just using the https module to handle communication with the 3rd party, but clearly I'd have to go at it at a lower level in order to take this approach.
The basic process would be:
Do the same thing as https.request in order to establish an ssl/tls connection to the 3rd party and encrypt the query string containing the user's credentials
Stop short of actually sending the encrypted data to the 3rd party and instead store it in my db
At a later time, "reconstruct" the https connection with the stored data and send it to the 3rd party, process response, win
That won't work, sorry. HTTPS renegotiates new session key each time, so data would look different over the wire with each new request.
Why do some scenarios require both ciphering and integrity whereas some scenarios require only ciphering ? What are the factors that decide this in the case of networking domain ?
Most systems that do ciphering also provide message integrity along the way, so your question is really posing a false dichotomy.
Ciphering is needed when you want that only authorized people can ACCESS TO SEE the data. Integrity is when authorized people can ACCESS TO MODIFY the data.
As you can see, both ciphering and integrity need an authentication and authorization phase before.
Ex: Data could be chipered with different private keys and deciphered with the relative different public keys. These phases depend onto the authentication & authorization phase.
Ex: when you connect via HTTPS, the first phase is a negotiation of the correct certificate. Typically the client authorize the server checking the trust of the certificate chain.
Ex: You have to access to data in your central DB. Data could be ciphered or not, but the access to the key and/or the data must be done only after an authentication and authorization check.
I hope my considerations help you
Encryption protects your text in transport, but it doesn't prove who you are. Adding an integrity control also proves your identity.
A scenario:
I can encrypt data between an ATM and a bank's server. No-one can sniff this traffic and decrypt it, so you can assume that it's "secure". But there's nothing to stop an intermediary from replaying those transactions. Or from replaying traffic seen at a different ATM location, even if the attacker doesn't know what the transaction actually contains. The transactions are not linked to any specific ATM as an entity. So if I withdraw $100 then an intermediary can replay the traffic exchange 10 times from multiple locations and cause me to withdraw $1000.
Adding an integrity control to the exchange can lock the transaction to only a single system and also prove that the transaction was not modified. So, for example, I can get the ATM to sign a digitally timestamped copy of each transaction. Now when the encrypted traffic is replayed, the server can tell that it's a false transaction as the timestamp will be old. Or if the a transaction from a similar ATM at a different location is replayed, then the server can also ascertain that it's talking to a different identity than the one actually expected. So while encryption secures the transaction channel, integrity makes sure that the two end-point decrypting the traffic are actually talking to the party that they expect.
Lets say i have a website mysite.com that will store some sensitive personal data (bank related)
On this website i have an oracle database with a USERS tables that will store the logins and passwords of users from mysite.com
I have a few questions :
How should i store passwords,encryption of course, but which ?
What should be the process for registration ? send an email to confirm is really necessary ?
Any good advices on login processes in general ?
For information, i m using Oracle APEX
You're storing bank related sensitive personal data. Don't hack your own solution. Use an existing, proven solution. Most likely you will also be running into all kinds of security and privacy laws, regulations and liabilities when dealing with such data. Find someone who knows these regulations and who can help you and advise you.
Don't try to do this yourself. "Anyone can build a security system they they themselves cannot break." - I think that's a Bruce Schneider quote. Heed it.
Edit to react on comment:
Even when dealing with private finance software you're probably dealing with bank account numbers, social security numbers, etcetera. So you are probably still running into various kinds of regulations.
Systems like OpenID and Oracle SSO only cover authentication. Regulations also dictate minimum security measures on how you should store data in your database, how you should treat backups, how you should deal with people (e.g. developers) accessing the database, etcetera, etcetera. If you don't follow these and something goes wrong, you're liable.
I really urge you to seek help from someone knowledgeable in the field. Explain them what you want to do, what you want to store, etcetera. They can tell you what (if any) regulations apply. Only then can you start looking at how you are going to implement this and what off-the-shelf components you can use.
Under no circumstance should a password be encrypted. The use of encryption implies that there is a decryption function and that would be a violation of CWE-257. Passwords must always be hashed, and SHA-256 is an excellent choice. The password should be salted with a cryptographic nonce. Authentication systems are highly simplistic when taking into consideration the other security systems you rely on.
You must be VERY CAREFUL to make sure that your system is free of SQL Injection. I recommend obtaining a copy of Acunetix($) NTO Spider ($$$) or wapiti(open source). In any case parameterized quires is the way to go.
Take a look at the answers to this question.
Passwords should be stored as a salted hash. Use a unique salt for each. For hashing there are better alternatives but SHA1 is alright for many purposes (its available via DBMS_CRYPTO). Even better go for SHA256 (using http://jakub.wartak.pl/blog/?p=124).
User registration confirmation really depends on the site. If you want to get users in quickly then you could allow them in after registration for a limited time until they click the activation link. All the activation really gets you is a real email address to associate with the user. Also consider captcha to prevent automated/scripted sign-up.
Login should enforce temporary lockout after some invalid attempts (and alert admins when successive lockouts are hit). Enforce a password complexity too.
OWASP has very good general advice on secure web app design.
Wikipedia has some information on Oracle Apex Security. Another comment suggested a web testing tool such as Acunetix or NTO Spider (I would suggest Burp instead), there is also a tool for testing the security of Apex applications through analysis of the source (ApexSec) - (disclosure, I work for this company).
You could also consider a third-party view on you application, be that penetration testing or code review. A Web Application Firewalls can provide some value depending on your context.