I am creating a chat service program that follows the server/client paradigm. That chat program exists as both a chat server and a chat client, and a user can either host the chatroom(and it will connect his client to that server), or he can join an existing one.
Clients connect via a direct IP address that the other user will tell them, such as gained from whatismyip.com, and a specified port number.
During any time in this chat program, one user can send a file to another user. This is initiated by asking the server to set up a handshake between the two users, with user A passing his IP through the server to user B, and user B calling the new service that user A created for file transfer. This eliminates the original chat server, and the users are connected via a direct IP using nettcp protocol.
Over this file transfer, the files are encrypted with AES after initially sending the AES private key via RSA encryption.
I want to know what kind of ways somebody can initiate a man in the middle attack here. Obviously I see the flaw I have in passing the IP address through the server to the other user, but right now I don't see any other way as I cannot have the server retrieve the IPV4 of the sender.
Is the way a man in the middle attack works, is that he can see that these two users are transferring files, and somehow pull the data stream to himself from both ends? Can he do this on an already ongoing file transfer session?
I'm trying to understand the way MITM attacks work so I can see if I can protect my program from such attacks... but if the only way to reliably do so is to use a certificate authority(of which I'm still learning about), please go ahead and tell me that.
After doing more searching, I found this great link explaining the different types of MITM attacks and how they work and are executed in great detail.
http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part1.html
There are a total of four parts.
Is the way a man in the middle attack works, is that he can see that
these two users are transferring files, and somehow pull the data
stream to himself from both ends? Can he do this on an already ongoing
file transfer session?
You need to define a threat model. The usual suspects are message insertion, deletion, tampering and reordering. Sometimes the attacker only needs to tamper with a message so you do the wrong thing. For example, he/she may need to flip a bit so "transfer $100 from A to B" changes to "transfer $900 from A to B". In this case, the attacker did not need to be in the middle or decrypt the message.
I'm trying to understand the way MITM attacks work so I can see if I
can protect my program from such attacks... but if the only way to
reliably do so is to use a certificate authority(of which I'm still
learning about), please go ahead and tell me that.
Rather than attempting to design a hardened protocol, perhaps you could use a protocol that already exists that addresses your concerns.
That protocol would be Z-Real-time Transport Protocol (ZRTP). The protocol is specified in RFC 6189, ZRTP: Media Path Key Agreement for Unicast Secure RTP.
ZRTP is a key exchange protocol that includes Short Authentication Strings (SAS) to keep out the MitM. Essentially, the SAS is a voice authentication that only needs to be performed once. You can omit the SAS check, though its not recommended. If you omit the check and the bad guy is not attacking, then everything is OK for current and future sessions.
Once you establish your first secure channel without adversarial tampering, all future sessions will be secure because of the way key agreement for the current session depends on earlier sessions. And the earliest session (first session) is known to be secure.
ZRTP also provides forward secrecy, so a compromise of the current session does not affect security of past sessions.
ZRTP does not require certification authorities or other (un)trusted third parties.
Dr. Matthew Green has a blog about ZRTP on his Cryptography Engineering site at Let's talk about ZRTP.
To answer your question about MitM, there's too much for a Stack Overflow answer. A great free book is Peter Guttman's Engineering Security. MitM is sometimes a goal of an attacker, but it not his/her only vector. Guttman's book looks at a number of threats, how humans act and react, why the attackers succeed, and how to design around many of the problems.
Related
I've coded the mobile api using Node.js, Redis & MongoDB. However right now I am looking for a concrete way to provide security in our system. The question I have inspired by the infamous principle of Auguste Kerckhoff;
"It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience"
After inspecting this principle I figure out that there is no safe way to secure data after a sniffer capturing the entire data package. Of course there are alternate ways like using an API key, using encryption algorithms like MD5 & MD6,Triple DES,SHA1 etc. However this also won't work if the entire data package is captured. And there is security precaution standarts like HTTPS, SSL certificates. However again if someone with talent captures the data package it can act just like a verified user in our system.
How would it be possible to apply a security method such that even though the entire data package is captured, the system would be able to distinguish the request coming from an outer source not from our verified user.
PS: I thought that applying a custom encryption algorithm with timestamp in order to prevent this problem could be a bit chaotic.
According to Kerckhoffs's principle "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." So the way cryptosystem, works is that the key is the only thing that can be used to decipher the system. If the key is fallen to the enemy then its all over.
In practice when you communicate over the internet or try to
authenticate your email account with the password. Your password is
never sent to, nor stored on the server in plain text. If you do then,
its not secure. The best security practice is not to store the
password at all (not even encrypted), but to store the salted hash of
the encrypted password.
That is one hash for one user. It is one way, you cannot get back user info, just test if it is in the database or not. Now even if the enemy takes control of the database, it cannot access your username/passwords.
Now coming to the point, it does not matter what you transmit in the communication channel, because the communication channel is the enemy!!! It is available to other users, anyone can sniff it. It is like enemies scanning each other on the radio.
The hash that has been sent over the channel can be sniffed and be used for authentication. True, but server can differentiate between spoofed attempt and the actual attempt, using HTTPS connection. Server tracks the HTTPS sessions and would ask to revalidate if something like this happens. HTTPS blocks use of sniffed data / MITM attacks. Even if sniffer gets hash (temporary ticket), he cannot do anything malicious, username and password cannot be cracked.
Thanks to Kerckhoff, our passwords are safe.
How to implement it on node.js ?? look for passport.js package. It implements the current standard OpenAuth.
My program sends a request to a web page over SSL and in the header (https://example.com/index.php?clientid=xxxx?spcode=xxxx) is a manager password used to determine if they are a valid client of my system before I send them a bunch of data.
If a rogue employee were to obtain this password by snooping on the local SSL data, he could potentially toy with client orders being sent and received if he were to guess order numbers (not hard).
I'm aware of how to use bcrypt to protect someone's password on my system. But how do I protect someone's password when someone else is using they're system?
I know you shouldn't send a pre-hashed password at risk of revealing your salt. Should I use some soft of temporary transmission hash (one that differs from what I store it in the DB with). I'm thinking this isn't the best way, so I'm asking you all for help. I've found some great tips here at Stack Exchange.
Thank you in advance for your time, everyone. I look forward to your thoughts.
Snooping on SSL can only be done by man-in-the-middling, and that's detected.
Consider how if you do so in fiddler, the browser reacts by complaining about the certificate. Of course, since you trust you not to spy on you, you okay it!
Comparably, you're going to see that you aren't dealing with a server with the correct certificate. If your app refuses to deal with other certificates, then it won't allow the SSL connection to be estabilshed, and there's no snooping.
I'd still recommend sending the password in authentication headers though, as per RFC 2617, NTLM, or so on. Especially if you move to also doing server-to-browser on top of the same system later, and wouldn't want them to be snoopable from the address bar.
Edit: Depending on what you write the app in, it can be temporarily allowing snooping for debugging purposes that proves trickier!
Are there any protocols which would allow 2 visitors to communicate securely through my website, without the possibility of me reading their messages?
Ask Google for End-to-End encryption like PGP/GPG. For a client-side browser-based implementation you might want to check out GPG encryption in JavaScript.
I just googled it and cannot tell if its really secure (not sending your private key to anyone). I just want to give you a point to start with.
EDIT: Looks like it does send the clients private key to your server to perform a server-based encryption. This is not what you want. But I am sure that a JavaScript implementation of GPG is possible even though I don't know if somebody has done it yet.
Yes; for example, this is what would happen if your server was a link in a communication protected by SSL/TLS.
The participants use a public-key encryption scheme to agree upon a secret, symmetric key; that is then used to encrypt their communication.
It's also possible for the participants to simply encrypt their messages with the public key of the intended receiver. That way, only the intended receiver can decrypt the message. This is not a very advanced scheme and probably vulnerable. (Among others, if an eavesdropper can guess exactly what is sent, he can encrypt that message with the intended recipient's public key and see if the result matches with what is being sent).
There is a lot of literature available on cryptographic protocols; for starters, here's a Wikipedia article on Key Agreement Protocols.
If we're talking about not possible then the second part to S.L. Barth's answer will achieve this with the exception that the key exchange must be done by some other means. This can be the phone or email or even another website but if it's done via your website then it's open to a man-in-the-middle attack. You can tell your users to do this, you just can't actually help them do it.
There is probably a javascript library somewhere that will implement GPG encryption so that all you have to do is make sure that every message is encrypted in the browser before it's sent to your web server. You can store the messages as long as you like, they're encrypted. Only the user with the correct private key will be able to decrypt it.
SSL and TLS as they are used by websites everywhere are vulnerable to man-in-the-middle attacks. The reason we don't hear much about these sorts of attacks is that most of the people in the middle are trustworthy so the attacks simply don't happen. The recent revoking of the CA certificates of DigiNotar and others was precisely because the Iranian Government were caught acting as a man-in-the-middle and decrypting their own citizen's SSL traffic.
If you're happy with preventing casual snooping by curious sysadmins, the key exchange can be done through your website as well.
One more thing: Security is hard.
Even if you do this with well-known encryption techniques, the chances of there being a flaw in the implementation will be very close to 1. This doesn't mean that those curious sysadmins will be able to accidentally read messages but it does mean that a determined and skilled adversary will be able to find a way in. As soon as you can afford it you should hire an expert to redesign or at the very least examine your protocol and implementation.
In general, such a secure link between your users without you being able to read and/or modify their messages is only possible if they have some way of identifying each other (or at least in one direction).
This might be a shared secret (like a passphrase) or a public key known to one (or certified by a CA known to one), where the other one has the corresponding private key.
On this one can build a secure protocol (using a key exchange and then symmetric encryption with MACs in both directions), like TLS does. (Another way, used often for instant messaging, is OTR, the Off-the-Record messaging protocol.)
Without a way to identify the other end point, you end up with a way of allowing man-in-the-middle attacks. SSL/TLS without certificates, or with certificates where the man-in-the-middle knows the corresponding private key, is insecure, as is every other similar encryption scheme.
Another issue is that you said visitors of my website. This looks like you would implement client-side cryptography in JavaScript, delivered from your website. Don't do this ... if the visitors do not trust you not to read their data, they also should not trust you to feed them non-malicious JavaScript, which might implement something else than you are claiming it does, again allowing a MITM, or even directly sending a copy of the data to you.
More details about this are discussed in Javascript Cryptography Considered Harmful (from a slightly different perspective).
How frequent (and/or sophisticated) are man-in-the-middle attacks?
About
In cryptography, the man-in-the-middle attack (often abbreviated MITM), or bucket-brigade attack, or sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, an attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle).
http://en.wikipedia.org/wiki/Man-in-the-middle_attack
The reason I ask is to try and gauge whether it's worth the added overhead of encrypting important sections of the content I'm sending to the user or whether it's safe to just go ahead and send it unencrypted.
Note: I know this isn't strictly a "programming" question insofar as there is no code solution, however it influences coding decisions and is coding-based, so it still seems appropriate.
It doesn't take a MITM attack to read data that hasn't been encrypted at all. A MITM attack is used to allow an attacker to read data that has been encrypted.
Edit: The relevant question with respect to MITM attacks is not whether you should do encryption at all. It's whether you should do some sort of authentication (i.e., verifying the identity of the remote party) while you set up an encrypted connection.
With no encryption at all, a "snooper" just looks at your data as it goes through, and sees exactly what's there. A MITM attack applies when you do encryption, but don't verify who you're sending the encrypted data to. In this case, the attacker inserts himself in the middle of the conversation -- you connect to the attacker, and send him encrypted data. He connects to the person you intended to talk to, and creates an encrypted connection to both of you. Then, as you send your data, he receives it, decrypts it with your key, re-encrypts it with the target's key, and sends it to the target. Likewise, any returned data he decrypts with the target's key, and re-encrypts with yours.
This way, it looks to both you and the target as if the communication is going normally -- but the attacker can read everything you send. If you don't encrypt the data at all, though, none of this is necessary -- since you're sending plain text, the attacker can just look at it as it goes by.
The MITM attack is not necessarily thwarted by encryption. For example, if you encrypt using a so-called "self-signed certificate," then your communications will be encrypted, and yet a MITM attack could still occur. For example, with a self-signed cert, if you load "Fiddler" onto the client box, it will perform a MITM exercise so that it can watch all the traffic. The client and the server will not realize that the MITM is happening.
If you use real PKI (a true trusted 3rd party is involved), then MITM isn't possible.
In any case, MITM is fairly easy to achieve, if the value of your data is "worth it" to the attacker.
Depends on the application, but if the data being sent is at all sensitive, definitely guard against man in the middle! It is a very relevant danger especially with rise of Wi-Fi, and very easy to do; a friend and I were able to replicate the Gmail MIMA last year with little difficulty.
I would refer you to the Internet Storm Center (isc.sans.org) for any questions about frequency of attack types on the Internet.
Keep in mind that MITM is a very broad term, and you seem to be more worried specifically with just session sniffing (i.e., eavesdropping) attacks. Sniffing attacks are trivial to perform. A full MITM facilitates modification of the session, which can have different implications than simply viewing the information. This modification requires a bit more sophistication, but not custom tools.
Using TLS/SSL on your site will provide protection of the data from prying eyes and ensure that clients are indeed communicating with the correct server.
To address the note on coding - whether you decide to use cryptography or not, you should be engineering your web app such that it would not be onerous to add crypto later.
Any time you talk about security, it's always in context of sensitivity of your data. The more valuable your secret is to someone, the more determined they will be to obtain it, and the more resources they'll expand. Conversely, the more valuable it is to you to keep it secret, the more resources you should expand protecting it.
Man in the middle attacks are pretty accessible to anyone, especially on public networks. It's up to you to decide if you want anyone to be able to read your data or not...
Quite simply, what is the criteria a website must meet for it to need SSL certificate?
Website is not ecommerce but will take user information, contact details and event information.
Even if not technically required does SSL just provide users with added 'trust' in the site?
Cheers
Use SSL when you are collecting sensitive information from your users, which (IMO) includes contact details. Personally I try and avoid submitting personal details about myself over an unencrypted channel.
In the end it's a judgement call. However, if you're collecting addresses, phone numbers, bank details, or anything that can be physically traced back to the user I'd recommend using SSL.
Obviously this only applies if your transport method is insecure (which the Internet, by definition, is). If you're running your website over an already-secure channel (like an internal network, where you trust your users, then there's not much point).
However, if you do decide to use SSL, make sure you get a valid, signed certificate! SSL without a signed certificate is kind of pointless, since it means your end users cannot trust the authenticity of the certificate. This unfortunately costs money, which is why many small websites don't bother.
SSL is all about trust - the certificates are signed by a "trusted" authority, so users can be sure that they are dealing with the proper certificate holders (as opposed to someone performing a man-in-the-middle attack). Obviously this trust is not ultimate - but it's an added step to providing a safe data channel for user information.
I would want to use SSL for any area of any website where personal information is being transmitted e.g. Login, Registration, Account Settings, Contact Details, User Information.
Take a look at the data being shown and ask yourself if you would want to leave that information posted around about you without any protection - go from there.
Whenever you cannot trust the wire - Whenever there is a chance of somebody snooping in to whatever is being sent over the wire (network hub, MITM vulnerability etc.) and whatever is being sent on the wire may contain stuff which at least a small subsection of your customer base will not like anyone to have access to.
Interestingly, SSL combines two components of security, they are:
Encryption
Identification
Encryption
Typically people use SSL because it encrypts the sending of data to the server. This is important if you are taking passwords, but critically important if you are taking credit card information. For this purpose, generally people have SSL for only that page. This isn't perfect, because the non-secure page you land at may have been spoofed, hence your already at the wrong site, so it doesn't really matter if it's encrypted.
Which brings us to ...
Identification
The identification component of SSL is also interesting. PayPal, for example, like their certificates because it is supposed to "prove" that PayPal bought it. Sadly, users don't care or notice this, despite some improvements in browser UI's.
Rarely is it necessary, or worthwhile, to get a certificate for identification (of the server), and IMHO, the two components of SSL should be separated (but that's another story :p). But some may argue that it is useful. I'm not one of those people.