I'm wondering if I should add an SSL layer between my server and client. I'm not handling any confidential data, but there is a very small chance someone might want to hack transmissions in order to gain intelligence (this is a game by the way). Now the amounts of data to be processed are considerable when compared to a small website and although the added security might be nice the most likely hackers would be users themselves, so I feel SSL would be a waste of time, but would like to hear about others experiences.
Thanks
This sounds like an optimization question. If you have information that you feel is valuable, start with SSL (a relatively easy security solution to try out). Once you have things working, benchmark the system with and without. If you feel that the performance hit is worth spending time on to try and optimize away, do that. If not, you're done!
Are users logging in with a username and password? If so, I think it's worth protecting. After all, users may end up using a password that they use for secure purposes elsewhere. I know they shouldn't, but...
Now suppose someone's snooping on your unprotected conversation. They get the user's password for your site, use it to log into the sensitive site, and they're off...
If you don't want to encrypt the information (and I do understand it's a bit of a pain getting hold of a valid certificate etc) then it's worth at least making it very clear to users that their data is unencrypted, and emphatically urge them not to use a password they use elsewhere.
If your worried about your clients hacking your data transmission ssl buys you nothing. Its channel security and if they own the client its relatively trivial to setup a man in the middle session where they can view your transmission unencrypted.
If your worried about users hacking others users data transmissions then ssl is a good and relatively simple security measure.
SSL should be used since you don't know what exploits or problems will occur in the future.
Confidentiality is only one way of considering whether you need SSL, if you are transmitting any personal data then I would want it secured. In some countries, you may be in breach of data protection laws by not using SSL.
There are other methods of protecting the data you transmit such as encrypting the payload with a PGP key before transmission and decrypting on the server.
No. If player X is not between player Y and the server, the only data he can get by hacking the way you are talking about is data the server is sending to player X. And that data is not protectable at all, since his machine must be able to extract it anyways. You may as well just zip it rather than using SSL: the level of protection will not differ by much. Instead, just make sure you don't send player X any data that he should not have. It's unlikely for someone to use a man-in-the-middle type of attack on a game.
If the game is known to be other than fair because it is insecure, I'd worry that it would cease to be of interest to anyone but the cheaters.
Besides securing the data stream, is it possible to pare down what you're sending already? Or compress it?
More information is needed to make an intelligent decision, but you don't have to use SSL to secure your data. You could always use another algorithm and a shared secret between the client and server, or public/private keys. You would then have better control over which bits to secure and which bits to leave open.
In general things like logins should always be encrypted using SSL. You could exchange a new set of keys over the SSL channel and then switch to non-SSL using the keys to protect the sensitive data.
SSL is considered by some to be a fix for a problem that (almost) doesn't exist. It's very hard to actually tap the wire and extract unencrypted information. Almost nobody does it.
If you look at the case of buying from an online store, what's a lot more likely to happen, is that they hack into the server, and download the entire database of transactions. In an ideal system, you would never even send your credit card credentials to the reseller, just a signed certificate from the credit card company stating that the transaction has already been authorized. However in the early days of the internet, that proved to be too difficult a system to set up, but it would have been the more correct solution. In the end they opted for the less effective, but easier to implement system.
Now on to your question. In your case, I can't see SSL offering much. If somebody want's to set up a program to monitor what is being sent to/from the network, it can still be done, as they can just place the hooks to capture the data before it's actually encrypted. If you're worried about third parties, or opponents they are playing against, sniffing the wire to figure out information about the game they shouldn't have access to, such as chat between teammates of the other team. Well, I would say the risk there is pretty minimal, and not worth addressing.
In addition to the notes about about encrypting usernames and passwords during transmission, SSL also prevents Man in the Middle attacks at the expense of adding overhead to every request.
The catch is that you must have some way of letting the client know that your particular certificate is valid... or more precisely, that it's the only valid one for your game.
Which also brings up the problem of how you tell the game when a new certificate replaces the old one after the old one expires.
Seriously, though, unless this is a subscription game of some sort, SSL is probably overkill.
Related
This is a general security question and will probably end up in a discussion. I started to put the question on the Information Security site, but that site is for security experts, and I'm not an expert.
When I pay bills, and shop online, sometimes I save my credit card info on the website in use, sometimes I don't. In general, is it safer to store a credit card on a website, or to re type the information every time?
The tradeoff I see is sending your data over the wire numerous times, where any point along the path might be compromised, versus leaving it sitting on a server for a hacker. I would think saving the info on a website is riskier, because the amount of time the information is available for a hacker is much longer. And if the information is sitting on multiple websites/servers, then the risk is even greater. Maybe I'm wrong.
I guess the card information has to go over the wire again when making purchases, even if it is saved on a server, albeit there would be less hops, so perhaps there are no security advantages to saving the info on a website.
It is always safer to type it in each time. The issue here is that you can't always solidly know how someone else (ie, a website) is going to store your data. Sure, they may encrypt it, but it could be a bad encryption cipher, or it could be a great one. You don't know. And because you don't know it's safer to keep it to yourself, and type it in each time.
However, keep in mind that unless you have a secure connection (https://) to the website you are entering your credit card data on, that data would be sent in cleartext. Cleartext meaning unencrypted data. Be weary of public wifi too. Sometimes they can replace the certificates used to encrypt websites with their own, and despite it being "secure", they would be able to read the data.
Short Answer: Only input sensitive data on networks you trust, like your home. And invest in a VPN if you want security no matter where you are.
I'm on my last steps to open my website, but the only thing that drove me crazy is the php user management. I found a lot of resources about building these systems and I believe that I can write them in my own way. The thing is that when it comes to security I get so freaking out what to go with. For example, when it comes to sending sensitive information over SSL, some people suggest to make sure that the info is encrypted in the registration form so that attacker can't hack it. And some other suggest to make sure that the debugging messages don't show when an error happen so that the attacker can't retrace the links .etc.
now as I read from here and there that md5 is not safe anymore so I'm wondering how would hash new user password and etc... I found a link to some programmers who already offer some user management, but not sure if they are good enough since I'm concerned about security as a priority CodeCanyon
so now what are the security measures that I have to be focusing on?
are there any resources related to that?
Thanks,
You don't have to (you shouldn't) choose between the different things people tell you to implement. Good security is always layered, meaning that you implement as many protections as you can. This approach has multiple purposes. Each layer can prevent different attacks. Each layer can prevent attackers with different experience. Each layer can increase the time needed for an attacker.
Here are some tipps useful for authentication systems.
Don't show debugging outputs
Don't use MD5 hashes. SHA2 or even better, bcrypt are much better
Use salts when storing passwords
Use nonces on your forms (one time tokens)
Always require SSL encryption between server and client
When accessing your database on the server, make sure that information leakage or its client-side manipulation not possible (eg.
avoid injection attacks, with database drivers use prepared
statements, etc.)
Make sure all failed logins (no matter what the reason) take the same amount of time to prevent timing attacks
When a logged-in user starts a risky operation (changing pwd, payment etc.), re-authgenticate him
Never store passwords cleartext, not ever, not anywhere
Require a minimum complexity for the password
!!! Secure your php sessions (another large topic, worth its own discussion) -
As you can see, there a lot you can do (and more people will probably tell you even more stuff), what you really should do depends on the risks you are willing to accept. But never rely on a single security measure, always have a layered approach.
Answering your direct question: It has been proven that MD5 does have collisions and there are rainbow tables floating around (see Wikipedia). PHP does have quite some hash functions available all having different advantages and disadvantages. Please also see the comment section on php.net.
Concerning general web application security I'd recommend you take a look at the OWASP project that is about making web applications more secure. A good start would be to take a look at the Top Ten security vunerabilities ("Top Ten" in the blue box).
use sha1 for storing password , prevent sql injection and xss script as input field.
session hijacking , fixation prevention.
At first you should send your data via SSL (TSL) to the server, this will encrypt. Also you should use a CSRF protection for any form you send to the server.
When you have implemented your functions and they work you should try to hack your site by yourself. Try to inject SQL, JS through the forms, try to manipulate the date after the form was send, you can also try to produce erros that will be written to you PHP error log even that could be executed if your server settings are weak. (http://en.wikipedia.org/wiki/Hardening_(computing))
When you store the password in your database use an seeded hash function, if anyone is able to hack your database and get the hashs he will not be able to encrypt them without the seed.
Your will find many information about all the techniques via google.
I can appreciate that seeing "basic auth" and "safe enough" in the same sentence is a lot like reading "Is parachuting without a parachute still safe?", so I'll do my best to clarify what I am getting at.
From what I've seen online, people typically describe basic HTTP auth as being unsecured due to the credentials being passed in plain text from the client to the server; this leaves you open to having your credentials sniffed by a nefarious person or man-in-the-middle in a network configuration where your traffic may be passing through an untrusted point of access (e.g. an open AP at a coffee shop).
To keep the conversation between you and the server secure, the solution is to typically use an SSL-based connection, where your credentials might be sent in plain text, but the communication channel between you and the server is itself secured.
So, onto my question...
In the situation of replicating one CouchDB instance from an EC2 instance in one region (e.g. us-west) to another CouchDB instance in another region (e.g. singapore) the network traffic will be traveling across a path of what I would consider "trusted" backbone servers.
Given that (assuming I am not replicating highly sensitive data) would anyone/everyone consider basic HTTP auth for CouchDB replication sufficiently secure?
If not, please clarify what scenarios I am missing here that would make this setup unacceptable. I do understand for sensitive data this is not appropriate, I just want to better understand the ins and outs for non-sensitive data replicated over a relatively-trusted network.
Bob is right, it is better to err on the side of caution, but I disagree. Bob could be right in this case (see details below), but the problem with his general approach is that it ignores the cost of paranoia. It leaves "peace dividend" money on the table. I prefer Bruce Schneier's assessment that it is a trade-off.
Short answer
Start replicating now! Do not worry about HTTPS.
The greatest risk is not wire sniffing, but your own human error, followed by software bugs, which could destroy or corrupt your data. Make a replica!. If you will replicate regularly, plan to move to HTTPS or something equivalent (SSH tunnel, stunnel, VPN).
Rationale
Is HTTPS is easy with CouchDB 1.1? It is as easy as HTTPS can possibly be, or in other words, no, it is not easy.
You have to make an SSL key pair, purchase a certificate or run your own certificate authority—you're not foolish enough to self-sign, of course! The user's hashed password is plainly visible from your remote couch! To protect against cracking, will you implement bi-directional SSL authentication? Does CouchDB support that? Maybe you need a VPN instead? What about the security of your key files? Don't check them into Subversion! And don't bundle them into your EC2 AMI! That defeats the purpose. You have to keep them separate and safe. When you deploy or restore from backup, copy them manually. Also, password-protect them so if somebody gets the files, they can't steal (or worse, modify!) your data. When you start CouchDB or replicate, you must manually input the password before replication will work.
In a nutshell, every security decision has a cost.
A similar question is, "should I lock my house at night? It depends. Your profile says you are in Tuscon, so you know that some neighborhoods are safe, while others are not. Yes, it is always safer to always lock all of your doors all of the time. But what is the cost to your time and mental health? The analogy breaks down a bit because time invested in worst-case security preparedness is much greater than twisting a bolt lock.
Amazon EC2 is a moderately safe neighborhood. The major risks are opportunistic, broad-spectrum scans for common errors. Basically, organized crime is scanning for common SSH accounts and web apps like Wordpress, so they can a credit card or other database.
You are a small fish in a gigantic ocean. Nobody cares about you specifically. Unless you are specifically targeted by a government or organized crime, or somebody with resources and motivation (hey, it's CouchDB—that happens!), then it's inefficient to worry about the boogeyman. Your adversaries are casting broad nets to get the biggest catch. Nobody is trying to spear-fish you.
I look at it like high-school integral calculus: measuring the area under the curve. Time goes to the right (x-axis). Risky behavior goes up (y-axis). When you do something risky you saved time and effort, but the the graph spikes upward. When you do something the safe way, it costs time and effort, but the graph moves down. Your goal is to minimize the long-term area under the curve, but each decision is case-by-case. Every day, most Americans ride in automobiles: the single most risky behavior in American life. We intuitively understand the risk-benefit trade-off. Activity on the Internet is the same.
As you imply, basic authentication without transport layer security is 100% insecure. Anyone on EC2 that can sniff your packets can see your password. Assuming that no one can is a mistake.
In CouchDB 1.1, you can enable native SSL. In earlier version, use stunnel. Adding SSL/TLS protection is so simple that there's really no excuse not to.
I just found this statement from Amazon which may help anyone trying to understand the risk of packet sniffing on EC2.
Packet sniffing by other tenants: It is not possible for a virtual instance running in promiscuous mode to receive or "sniff" traffic that is intended for a different virtual instance. While customers can place their interfaces into promiscuous mode, the hypervisor will not deliver any traffic to them that is not addressed to them. This includes two virtual instances that are owned by the same customer, even if they are located on the same physical host. Attacks such as ARP cache poisoning do not work within EC2. While Amazon EC2 does provide ample protection against one customer inadvertently or maliciously attempting to view another's data, as a standard practice customers should encrypt sensitive traffic.
http://aws.amazon.com/articles/1697
Assuming we have a server S and a few Clients (C) and whenever a client update a server, an internal database on the server is updated and replicated to the other clients. This is all done using sockets in an intranet environment.
I believe that an attacker can fairly easily sniff this plain text traffic. My colleagues believe I am overly paranoid because we are behind a firewall.
Am I being overly paranoid? Do you know of any exploit (link please) that took advantage of a situation such as this and what ca be done differently. Clients were rewritten in Java but server is still using C++.
Any thing in code can protect against an attack?
Inside your company's firewall, you're fairly safe from direct hack attacks from the outside. However, statistics that I won't trouble to dig out claim that most of the damage to a business' data is done from the INside. Most of that is simple accident, but there are various reasons for employees to be disgruntled and not found out; and if your data is sensitive they could hurt your company this way.
There are also boatloads of laws about how to handle personal ID data. If the data you're processing is of that sort, treating it carelessly within your company could also open your company up to litigation.
The solution is to use SSL connections. You want to use a pre-packaged library for this. You provide private/public keys for both ends and keep the private keys well hidden with the usual file access privileges, and the problem of sniffing is mostly taken care of.
SSL provides both encryption and authentication. Java has it built in and OpenSSL is a commonly used library for C/C++.
Your colleagues are naïve.
One high-profile attack occurred at Heartland Payment Systems, a credit card processor that one would expect to be extremely careful about security. Assuming that internal communications behind their firewall were safe, they failed to use something like SSL to ensure their privacy. Hackers were able to eavesdrop on that traffic, and extract sensitive data from the system.
Here is another story with a little more description of the attack itself:
Described by Baldwin as "quite a
sophisticated attack," he says it has
been challenging to discover exactly
how it happened. The forensic teams
found that hackers "were grabbing
numbers with sniffer malware as it
went over our processing platform,"
Baldwin says. "Unfortunately, we are
confident that card holder names and
numbers were exposed." Data, including
card transactions sent over
Heartland's internal processing
platform, is sent unencrypted, he
explains, "As the transaction is being
processed, it has to be in unencrypted
form to get the authorization request
out."
You can do many things to prevent a man in the middle attack. For most internal data, within a firewall/IDS protected network you really don't need to secure it. However, if you do wish to protect the data you can do the following:
Use PGP encryption to sign and encrypt messages
Encrypt sensitive messages
Use hash functions to verify that the message sent has not been modified.
It is a good standard operating proceedure to secure all data, however securing data has very large costs. With secure channels you need to have a certificate authority, and allow for extra processing on all machines that are involved in communication.
You're being paranoid. You're talking about data moving across an, ideally, secured internal network.
Can information be sniffed? Yea, it can. But it's sniffed by someone who has already breached network security and got within the firewall. That can be done in innumerable ways.
Basically, for the VAST majority of businesses, no reason to encrypt internal traffic. There are almost always far far easier ways of getting information, from inside the company, without even approaching "sniffing" the network. Most such "attacks" are from people who are simply authorized to see the data in the first place, and already have a credential.
The solution is not to encrypt all of your traffic, the solution is to monitor and limit access, so that if any data is compromised, it is easier to detect who did it, and what they had access to.
Finally, consider, the sys admins, and DBAs pretty much have carte blanche to the entire system anyway, as inevitably, someone always needs to have that kind of access. It's simply not practical to encrypt everything to keep it away from prying eyes.
Finally, you're making a big ado about something that is just as likely written on a sticky tacked on the bottom of someone's monitor anyway.
Do you have passwords on your databases? I certainly hope the answer to that is yes. Nobody would believe that password protecting a database is overly paranoid. Why wouldn't you have at least the same level of security* on the same data flowing over your network. Just like an unprotected DB, unprotected data flow over the network is vulnerable not only to sniffing but is also mutable by a malicious attacker. That is how I would frame the discussion.
*By same level of security I mean use SSL as some have suggested, or simply encrypt the data using one of the many available encryption libraries around if you must use raw sockets.
Just about every "important" application I've used relies on SSL or some other encryption methodology.
Just because you're on the intranet doesn't mean you may not have malicious code running on some server or client that may be trying to sniff traffic.
An attacker which has access to a device inside your network that offers him the possibility to sniff the entire traffic or the traffic between a client and a server is the minimum required.
Anyway, if the attacker is already inside, sniffing should be just one of the problems you'll have to take into consideration.
There are not many companies I know of which use secure sockets between clients and servers inside an intranet, mostly because of the higher costs and lower performance.
I'm already using salted hashing to store passwords in my database, which means that I should be immune to rainbow table attacks.
I had a thought, though: what if someone does get hold of my database? It contains the users' email addresses. I can't really hash these, because I'll be using them to send notification emails, etc..
Should I encrypt them?
Bruce Schneier has a good response to this kind of problem.
Cryptography is not the solution to your security problems. It might be part of the solution, or it might be part of the problem. In many situations, cryptography starts out by making the problem worse, and it isn't at all clear that using cryptography is an improvement.
Essentially encrypting your emails in the database 'just in case' is not really making the database more secure. Where are the keys stored for the database? What file permissions are used for these keys? Is the database accesable publically? Why? What kind of account restrictions are in place for these accounts? Where is the machine stored, who has physical access to this box? What about remote login/ssh access etc. etc. etc.
So I guess you can encrypt the emails if you want, but if that is the extent of the security of the system then it really isn't doing much, and would actually make the job of maintaining the database harder.
Of course this could be part of an extensive security policy for your system - if so then great!
I'm not saying that it is a bad idea - But why have a lock on the door from Deadlocks'R'us which cost $5000 when they can cut through the plywood around the door? Or come in through the window which you left open? Or even worse they find the key which was left under the doormat. Security of a system is only as good as the weakest link. If they have root access then they can pretty much do what they want.
Steve Morgan makes a good point that even if they cannot understand the email addresses, they can still do a lot of harm (which could be mitigated if they only had SELECT access)
Its also important to know what your reasons are for storing the email address at all. I might have gone a bit overboard with this answer, but my point is do you really need to store an email address for an account? The most secure data is data that doesn't exist.
I realize this is a dead topic, but I agree with Arjan's logic behind this. There are a few things I'd like to point out:
Someone can retrieve data from your database without retrieving your source code (i.e. SQL injection, third-party db's). With this in mind, it's reasonable to consider using an encryption with a key. Albeit, this is only an added measure of security, not the security...this is for someone who wants to keep the email more private than plaintext,
In the off chance something is overlooked during an update, or an attacker manages to retrieve the emails.
IMO: If you plan on encrypting an email, store a salted hash of it as well. Then you can use the hash for validation, and spare the overhead of constantly using encryption to find a massive string of data. Then have a separate private function to retrieve and decrypt your emails when you need to use one.
In common with most security requirements, you need to understand the level of threat.
What damage can be done if the email addresses are compromised?
What's the chance of it happening?
The damage done if email addresses are REPLACED could be much greater than if they're EXPOSED. Especially if you're, for example, using the email address to verify password resets to a secure system.
The chance of the passwords being either replaced or exposed is much reduced if you hash them, but it depends what other controls you have in place.
I would say it depends on the application of your database.
The biggest problem is, where do you store the encryption key? Because if the hacker has excess to anything more than your DB, all your efforts are probably wasted. (Remember, your application will need that encryption key to decrypt and encrypt so eventually the hacker will find the encryption key and used encryption scheme).
Pro:
A leak of your DB only will not expose the e-mail addresses.
Cons:
Encryption means performance loss.
Allot of database actions will be harder if not impossible.
Don't accidentally conflate encryption with obfuscation. We commonly obfuscate emails to prevent spam. Lots of web sites will have "webmaster _at_ mysite.com" to slow down crawlers from parsing the email address as a potential spam target. That should be done in the HTML templates -- there's no value to doing this in persistent database storage.
We don't encrypt anything unless we need to keep it secret during transmission. When and where will your data being transmitted?
The SQL statements are transmitted from client to server; is that on the same box or over a secure connection?
If your server is compromised, you have an unintentional transmission. If you're worried about this, then you should perhaps be securing your server. You have external threats as well as internal threats. Are ALL users (external and internal) properly authenticated and authorized?
During backups you have an intentional transmission to backup media; is this done using a secure backup strategy that encrypts as it goes?
Both SQL Server and Oracle (and I believe also others DBs) support encryption of data at the database level. If you want to encrypt something why don't simply abstract the access to the data that could be encrypted on the database server side and left the user choose if use the encrypted data (in this case the SQL command will be different) or not. If the user want to user encrypted data then it can configure the database server and all the maintenance work connected with key management is made using standard DBA tool, made from the DB vendor and not from you.
A copy of my answer at What is the best and safest way to store user email addresses in the database?, just for the sake of the search...
In general I agree with others saying it's not worth the effort. However, I disagree that anyone who can access your database can probably also get your keys. That's certainly not true for SQL Injection, and may not be true for backup copies that are somehow lost or forgotten about. And I feel an email address is a personal detail, so I wouldn't care about spam but about the personal consequences when the addresses are revealed.
Of course, when you're afraid of SQL Injection then you should make sure such injection is prohibited. And backup copies should be encrypted themselves.
Still, for some online communities the members might definitely not want others to know that they are a member (like related to mental healthcare, financial help, medical and sexual advice, adult entertainment, politics, ...). In those cases, storing as few personal details as possible and encrypting those that are required (note that database-level encryption does not prevent the details from showing using SQL Injection), might not be such a bad idea. Again: treat an email address as such personal detail.
For many sites the above is probably not the case, and you should focus on prohibiting SELECT * FROM through SQL Injection, and making sure visitors cannot somehow get to someone else's personal profile or order information by changing the URL.
It's worth to encrypt data in Databases, it's not making it a bit more difficult but way more difficult when its encrypted in the right way so stop philosophy and encrypt the sensitive data ;)
#Roo
I somewhat agree to what you are saying but isn't it worth encrypting the data just to make it a little more difficult for someone to get it?
With your reasoning, it would be useless to have locks or alarms in your house, because they can also easily be compromised.
My reply:
I would say that if you have sensitive data that you don't want to fall in the wrong hands, you should probably do it as hard as you can for a hacker to get it, even if it's not 100% fool proof.
I miss one important answer here.
When you have European users, you have to comply with the GDPR rules.
Email addresses are considered personal data meaning Art.5 does apply on email addresses.
processed in a manner that ensures appropriate security of the
personal data, including protection against unauthorised or unlawful
processing and against accidental loss, destruction or damage, using
appropriate technical or organisational measures (‘integrity and
confidentiality’).
Of course this does not say that you must encrypt email addresses. But by encrypting the data you do protect it from snooping employees. And protect yourself as a developer from requests to make a manual change in the database.
You really have to weigh your worst case senario of someone obtaining those email addresses, the likelihood of someone obtaining them, and your extra effort/time needed to impliement the change.