Im trying to design a payments API, and it requires the sending of CC info over the wire. So for this I was thinking of using a public key to encrypt the CC info and decrypt it on the server. Keep in mind that the connection is https also. Any suggestions on the topic?
If the connection is https encrypting it a second time won't do any good, except if someone breaks SSL/TLS. In that case trust me your API will be the least of the world's problems..
If the connection is HTTPS, no need to encrypt the CC details.
In contrast to the earlier answers I would strongly suggest you read up on PCI-DSS. Basically you want to keep the card number encrypted until it is absolutely needed in plain text, such as when authorizing or settling. Its not clear what exactly your api calls will do, but at a guess you almost certainly don't want the card number to appear in plain text as soon as it hits your webservice.
In addition if you have a client side component that captures card details, then that will fall under the scrutiny of PA-DSS.
Related
A little background: I am going to be constructing a webserver, likely the most up to date version of apache when I get around to it. It is going to be updated with sensory information from a makeshift security system I have.
As a counterpart, I am designing an app to go along with it, that will automatically contact the webserver and pull the sensory information about once every 1.5 minutes.
I want to have an authentication method so that the average Bob can't see this information, mostly due to the fact that there will be some command and control as part of the server as well.
The question: I feel like a simple username and password is the wrong way to go about this since it isn't dynamic and theoretically seeing the same credentials sent that frequent could be dangerous, so is there any other authentication method that could mitigate this?
The question pt. 2: Obviously I want an encrypted channel, will https stumble over itself if it tries to renegotiate every minute and a half?
I haven't begun this project yet much less chosen any language to write it in, meaning I am super open minded to suggestions, any help is greatly appreciated.
The question: I feel like a simple username and password is the wrong
way to go about this since it isn't dynamic and theoretically seeing
the same credentials sent that frequent could be dangerous, so is
there any other authentication method that could mitigate this?
You could use Google Sign-In to allow log on via a Google account.
Or you could implement two factor authentication with say Google Authenticator or via SMS to prove that the user logging in has more than one factor of authentication. These factors could be:
Something you know (e.g. password)
Something you have (e.g. phone that provides a One Time Password)
Edit: Having re-read your question - yes you are fine to authenticate with username and password (over HTTPS), however you should then store a session identifier client-side and simply send this in future rather than the username/password each time. This is more secure as it can be stored safely client-side, and if exposed the identifier can be easily revoked.
The question pt. 2: Obviously I want an encrypted channel, will https
stumble over itself if it tries to renegotiate every minute and a half?
Nope, this is what it is designed for. Browsers will keep open an HTTPS connection for a length of time. Additionally, they will use session resumption rather than executing a full HTTPS handshake in the case that a new connection needs to be established. Session resumption is much quicker than establishing a completely new session. See this article on the CloudFlare blog for more info.
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.
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!
I've done a little googling but have been a bit overwhelmed by the amount of information. Until now, I've been considering asking for a valid md5 hash for every API call but I realized that it wouldn't be a difficult task to hijack such a system. Would you guys be kind enough to provide me with a few links that might help me in my search? Thanks.
First, consider OAuth. It's somewhat of a standard for web-based APIs nowadays.
Second, some other potential resources -
A couple of decent blog entries:
http://blog.sonoasystems.com/detail/dont_roll_your_own_api_security_recommendations1/
http://blog.sonoasystems.com/detail/more_api_security_choices_oauth_ssl_saml_and_rolling_your_own/
A previous question:
Good approach for a web API token scheme?
I'd like to add some clarifying information to this question. The "use OAuth" answer is correct, but also loaded (given the spec is quite long and people who aren't familiar with it typically want to kill themselves after seeing it).
I wrote up a story-style tutorial on how to go from no security to HMAC-based security when designing a secure REST API here:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
This ends up being basically what is known as "2-legged OAuth"; because OAuth was originally intended to verifying client applications, the flow is 3-parts involving the authenticating service, the user staring at the screen and the service that wants to use the client's credentials.
2-legged OAuth (and what I outline in depth in that article) is intended for service APIs to authenticate between each other. For example, this is the approach Amazon Web Services uses for all their API calls.
The gist is that with any request over HTTP you have to consider the attack vector where some malicious man-in-the-middle is recording and replaying or changing your requests.
For example, you issue a POST to /user/create with name 'bob', well the man-in-the-middle can issue a POST to /user/delete with name 'bob' just to be nasty.
The client and server need some way to trust each other and the only way that can happen is via public/private keys.
You can't just pass the public/private keys back and forth NOR can you simply provide a unique token signed with the private key (which is typically what most people do and think that makes them safe), while that will identify the original request coming from the real client, it still leaves the arguments to the comment open to change.
For example, if I send:
/chargeCC?user=bob&amt=100.00&key=kjDSLKjdasdmiUDSkjh
where the key is my public key signed by my private key only a man-in-the-middle can intercept this call, and re-submit it to the server with an "amt" value of "10000.00" instead.
The key is that you have to include ALL the parameters you send in the hash calculation, so when the server gets it, it re-vets all the values by recalculating the same hash on its side.
REMINDER: Only the client and server know the private key.
This style of verification is called an "HMAC"; it is a checksum verifying the contents of the request.
Because hash generation is SO touchy and must be done EXACTLY the same on both the client and server in order to get the same hash, there are super-strict rules on exactly how all the values should be combined.
For example, these two lines provides VERY different hashes when you try and sign them with SHA-1:
/chargeCC&user=bob&amt=100
/chargeCC&amt=100&user=bob
A lot of the OAuth spec is spent describing that exact method of combination in excruciating detail, using terminology like "natural byte ordering" and other non-human-readable garbage.
It is important though, because if you get that combination of values wrong, the client and server cannot correctly vet each other's requests.
You also can't take shortcuts and just concatonate everything into a huge String, Amazon tried this with AWS Signature Version 1 and it turned out wrong.
I hope all of that helps, feel free to ask questions if you are stuck.
I'm writing a system where, as usual, the client is asking for a convenience "remember your credit card details" option.
I've told them that this is in all likelihood a no-go. However, I did have a good idea (tm) just now, and seeing that Good Ideas in Encryption(tm) are actually Bad Ideas (tm), I thought I'd put it up for review here and see what holes can be punched through it.
Essentially, I'm thinking of xor'ing the credit card information plus some message signature using a one time pad that's generated per client. This pad is stored as a cookie variable on the client's browser.
Next time that user tries to place a purchase, the pad is sent to the server, and if the server can properly decode its encrypted data, it shows the credit card information as already being filled. (The cc info isn't actually transmitted back). The server will never store the pad in anything more than memory or page file. In fact, I intend to have the pad be sent twice: once upon arrival on the CC page (where the server checks if it should ask for CC information), and once on CC submission to get the actual information.
The user will also be instructed that their information is "partially stored" in their cookie cache, meaning that they will expect that if their cookies are flushed, their CC information is lost.
Let me know where you think this scheme is horribly failing.
Sounds sketchy, and I'm pretty sure you're misusing the term "one time pad."
Instead of going this route, look into using a service like Authorize.net's Customer Information Management. Basically, you give them the card info, and they give you back an ID that you can use to charge the card. The ID is linked to the website's merchant account, and can't be used to charge the card with any other merchant.
It's much, much safer, and should get you the same results.
Note: I'm not endorsing Auth.net or its CIM. It's just the example I'm most familiar with.
Storing the pad client-side leaves it vulnerable to XSS, I would think.
Technologically: flawed.
Legally: probably flawed. talk to a lawyer.
A one time pad only works if the pad is securely kept secret. Storing it in a cookie definitely doesn't count as secure or secret (it's sent to and from the server, it's dropped onto the user's machine, which might be a public terminal or shared machine). This is a really bad idea. It's a clever idea but ultimately very flawed. I suggest you read the PCI compliance documentation and do what other people do which is (generally speaking):
Don't do it.
Use a payment processor that will securely store the CC and handle billing (i.e. PayPal).
Setup a separate and strongly secured payment gateway, this machine only processes credit card transactions, and it in turn accesses a secured machine that stores the credit card data.
Remember that storing credit card numbers will basically violate PCI and will probably violate any merchant agreements and might even be illegal in your jurisdiction (privacy laws, etc.), consult a lawyer please.
Don't do it. Seriously. Find a payment processor who will handle this for you.
If the credit card is being stored client side then you're storing it with the key which means it's vulnerable.
If you are storing the credit card server side then you don't need a key of an encryption key stored on the client.
It sounds like a very dangerous situation if what you are describing is a case where the user is not only not being given the option whether or not they want to store their details but is also going to have them re-populated without having to authenticate in any way. I'd be pretty happy if I came along to an internet cafe and got the credit card details fields pre-populated for me!