I was wondering if anyone has done some performance testing with two different approaches for security. Mostly concerned with the server side of things.
1) Using active directory, the user account is validated each time a message is sent.
2) Using certificate, each message is encrypted with a certificate.
My guess would be that decrypting the message is more computer intensive hence the active directory approach is likely to perform better.
You have a few mixed bits of security there.
Which ones do you require?
Securing a queue against access from accounts you don't want
Ensuring a message is from the account it says it is (authentication)
Ensuring no one can see the message body (encryption)
Let me know and I can give you a better idea of what works performancewise.
You write "Using active directory, the user account is validated each time a message is sent."
That doesn't sound right. All MSMQ does is put the SID of the sending user account in the message header. This is why you shouldn't rely on just setting account level access on queues as anyone can spoof the SID in an MSMQ message.
Cheers
John Breakwell
Being a starter on MSMQ, I will do my best to answer the question here.
[1.] Securing a queue against access from accounts you don't want
Answer: My understanding is that if I use a private queue, it will implicitly do that. In other words, if anyone does not know about it, then how "outsiders" can access it ?
[2.] Ensuring a message is from the account it says it is (authentication)
Answer: I can debate about this. I am not sure it will make a difference in my particular environment since everything is driven by a custom app with structured data sent. If data is not structured the way it should be, the message will simply be ignored.
[3.] Ensuring no one can see the message body (encryption)
Answer: More relevant here, I do think that some level of encryption to prevent any "peeking" of the data.
Finally, I was not aware that the SID was inside the message header.
Let me know how performance is affected but these various security settings. Also, what's your advice on security with regards to MSMQ ?
Thx for all the info...
Christian Martin
Related
I am working on a family networking app for Android that enables family members to share their location and track location of others simultaneously. You can suppose that this app is similar with Life360 or Sygic Family Locator. At first, I determined to use a MBaaS and then I completed its coding by using Parse. However, I realized that although a user read and write geolocation data per minute (of course, in some cases geolocation data is sent less frequently), the request traffic exceeds my forward-looking expectations. For this reason, I want to develop a well-grounded system but I have some doubts about whether Parse can still do its duty if number of users increases to 100-500k.
Considering all these, I am looking for an alternative method/service to set such a system. I think using a backend service like Parse is a moderate solution but not the best one. What are the possible ways to achieve this from bad to good? To exemplify, one of my friends say that I can use Sinch which is an instant messaging service in background between users that set the price considering number of active users. Nevertheless, it sounds weird to me, I have never seen such a usage of an instant messaging service as he said.
Your comments and suggestions will be highly appreciated. Thank you in advance.
Well sinch wouldn't handle location updates or storing of location data, that would be parse you are asking about.
And since you implied that the requests would be to much for your username maybe I wrongly assumed price was the problem with parse.
But to answer your question about sending location data I would probably throttle it if I where you to aile or so. No need for family members to know down to the feet in realtime. if there is a need for that I would probably inement a request method instead and ask the user for location when someone is interested.
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
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.
A common problem I find when dealing with non-technical users when supporting technical issues is "translating" what I'm hearing to what actually is causing the problem. In our current application we do things like provide error message details that can be forwarded to our support team, however my question is:
1. Is there an approach that any of you have implemented and found successful in helping the user provide quality information about application issues that can help in troubleshooting? If so what is that approach?
What I'm hoping for is a clever approach to designing error message displays in such a way that when the user communicates the issue, it is a better primer for quickly resolving the issue. Thanks!
I've found that logging of end user activities and errors is an effective tool as this reduces the amount of information you require from the end user.
You can also ask the end user to provide screenshots which typically captures URLs, input, error messages, etc..
EDIT: In my experience though, any prompt for information even when provided to help desk staff is typically ignored or misinterpreted. My suggestion is to capture as much information as you can automatically as that eliminates human error/oversight.
If your users aren't computer litterate, then you should use VNC to see what's happening on their computers. Despite network lag, you should be able to see more things happen than the user does
When your application encounters an error, have it log or "phone home" the actual error in addition to showing an error message to the user. The user can then send you the error logs (or you can look at them in your error database if the application "phones home"). This way you can get more detailed information directly from the application. Logging additional information about the application state will help to isolate what the user is doing when the error occurs. You may want to include the ability to turn this logging on/off so that it only occurs, or occurs at different levels, based on some flag. This would allow you to restrict some logging to only those situation that require extensive logging to narrow down the problem.