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.
Related
I would like to store user profile information. After researching a bit online, I am confused between the following options:
Use a LDAP server (example: Open DJ) - I can write Java clients which can interact with the LDAP server using LDAP APIs.
Store user profile in a database as a JSON document (like in Elastic DB) - The No SQL databases can then index the documents to improve lookup time.
What are the factors that I should keep in mind before selecting one of the approaches?
For a start, if you are storing passwords, then using LDAP is a no brainer IMO. See http://smart421.com/smart-identity-and-fraud/why-bother-with-an-ldap-anyway/ .
Otherwise I would recommend you do a PoC with each solutions (do not forget to add indexes for OpenDJ and you may also use Rest2LDAP) see how they fill your needs. Both products are open source so its easy to get started.
If your user population is a known group that may already have accounts in an existing LDAP repository, or where user account information needs to be shared between systems, then it makes sense to use and add on to the existing LDAP repository.
If you are starting out from scratch and have mainly external, unknown users who have no other interaction with your infrastructure but this one application, then LDAP is not a good choice imo because of the overhead that you are getting for creating and managing the server. Then a lightweight JSON approach seems better suited (even thought the L in LDAP stands for "lightweight").
The number of expected users is less of a consideration - you need to thread carefully with very large populations in either scenario.
See this questions as well for additional insights Reasons to store users' data in LDAP instead of RDBMS
For security reasons we are planning to disable all write access to classes. Client applications (android and IOS sdks) will only have read-only access to the Parse data(classes)
Data stored in parse servers will be only modified by cloud functions. The cloud functions will call
Parse.Cloud.useMasterKey();
We have come up with this solution because it is nearly impossible to hide parse application ids and parse client key from attackers/hackers.
So is this a good solution? Are there any drawbacks? Does "Parse.Cloud.useMasterKey()" method have performance implications?
Thank you...
This is pretty standard practice, you implement your own security in your Cloud Functions and use the master key.
In theory it might be more efficient using the master key as the Parse servers don't have to process the Roles/Users/ACLs at all when the master key is used. Of course you need to balance that with any extra check your security logic does.
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 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
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.