I'm building a secure payment portal.
We currently have two applications that will be using this. One is a web application, the other a desktop app. Both of these require users to login/authenticate, the same credentials can be used for either application.
I want to build an automatic login mechanism that will fill in all the various login/order details and be able to call this from either app mentioned above. I've been thinking that the best way to do this is to pass this information encrypted through the URL. ie https://mysite.com/TakePayment.aspx?id=GT2jkjh3....
Since we don't want to integrate the payment processing too tightly into the desktop app to reduce our PCI scope, we decided to have it open the browser to a central, secured payment page through a simple shell execute with the full URL causing the default browser to open that page.
Originally we were using AES for the encryption, but this is currently being re-examined as we would prefer not having to give out the key to the end user (AES is symmetric, symmetric encryption = both parties need the private key, why bother even encrypting then since we're going to be distributing the app?) So I'm looking at switching it over to use Public Key Encryption with the built in RSA routines within .NET
After coding up the RSA portion I noticed most examples on the net used 1024bits for the key-length, I went with this and now have our portal working with public key encryption, however the URLs generated are much much longer than when I was using AES so it made me start researching what the max limits for URLs are. http://www.boutell.com/newfaq/misc/urllength.html Says that IE is the limiting browser at about 2048 characters in the path portion. My initial tests with the RSA encryption show my urls will be around 1400 chars long.
My questions boil down to this:
1) Is there a better way for passing information from a desktop app to a website that I'm not thinking of? I'd prefer it be just as easy to use from another web page as it is from the desktop, hence my current solution.
2) Is 1024 bit RSA keys necessary? Or overkill for something like this? A shorter key would mean shorter encrypted text right?
3) Are there any other unforeseen problems with URLs in the 1200-1400 character range? Proxies? Firewalls? Web-Accelerators?
Thanks
Update 12/11/2011:
Come to find out, the method that we ended up going with here ended up biting us in the ass recently (or rather we found out about it today, even though the problem was a very sporadic and difficult one to track down..)
The plain text token that we encrypted was originally rather small, only a hundred bytes or so. This is what resulted in my test URLs being approximately 1400 bytes long. Through feature creep we've been required to add more data to the token, and the average URL length jumped to 1700-1800 in length.
Once the length of our plain text hits 173 characters long and above however, the URL length jumps again, this time up to 2080+ or so, which now causes problems for IE. After some investigation in how RSA encryption works, this should have been totally expected, but was an oversight on my part originally.
We're using 1024 bit RSA encryption, which means that the maximum data block size that can be encrypted is 1024/8 - 24 = 86 bytes, every 86 bytes needs to be "chopped up" and encrypted separately, so at 86 * 2 = 172, we're only encrypting two blocks, above that we're encrypting three, four, five, etc. By passing 172, our cipher text length grew so long the URL's are now too long.. I'm probably messing up the explanation a little here, but that's the general gist of it..
It seems we'll be looking at designing a better way for this to work, as it can be expected they'll want "more features" to be added in the future and thus our token will grow ever larger...
Assuming this is all logged in a database can you not pass the data back and forth using SSL web services. Then in the case of being able to quickly go from the desktop app to the web app make a rpc call to the website to generate a random key, pass that to the user and call a web page using that. Make the key valid for say 10 seconds meaning should a key be captured and broken it will have become invalid?
I have little experience with this kind of thing so I'm expecting many holes to be poked in the idea.
Related
I want to store a large file on a publicly accessible service, amazon, bittorrent, ipfs etc.
I want this file to be encrypted.
I know the common practice is to encrypt the file symmetrically with a complex password and then encrypt the password with the recipient public key, but I have a use case I need to deliver the key to each recipient so when the password leaks to public I know who did it.
So what I thought of was to encrypt the whole file with AES CBC then split it to chunks and encrypt only the first chunk asymmetrically.
Are there any logical mistakes in this idea? What should be the minimum size of the first chunk (in bytes or percentage of the whole file) so it's safe to say without decrypting the first one there is no way to decrypt the remaining ones.
Edit
Thanks for the answers
I'll elaborate a little more on the use case.
I'm planning to let users put (sell) files on decentralised storage using my platform (and I have no control over the nodes - lets assume it's global ipfs). To be compliant with the regulations files has to be encrypted and I have to have a way to block the access to it.
Because as stated before I wont be able to delete the files from all the nodes I thought of encrypting the files asymmetrically but this requires preparing a separate copy for each recipient and would take a lot of time.
That's how I came up with the idea of encrypting only a part of the file, moreover this would be done by a re-encryption proxy so the seller would only need to prepare the re-encryption key and the amount of excessive data on the network would be minimal (only one shard per buyer).
Still when the authorities approach me that I'm sharing illegal content I could tell them the file is encrypted and the only guys that downloaded it are these public keys owners.
Apparently some things are misunderstood
have a use case I need to deliver the key to each recipient so when the password leaks to public I know who did it.
Lets assume the file is encrypted with a single symetric encryption key (password in ypur case) . You may encrypt the password using recipients' personal public key, but once the password is released, you have no means to find out who leaked/released it.
split it to chunks and encrypt only the first chunk asymmetrically
that makes no sense / reason (at least I did not find any reason why this would help you to achive the stated use case)
note: the reason why hybrid encryption is used is that asymmetric encryption (RSA) is feasible to encrypt only limited amount of data (e. g. symmetric encr. key)
your problem is not solvable by the means of classic cryptography
when we take a look at your problem one might think your usecase is like so often in cryptography: confidentiality, but it is not
confidentiality in a cryptographic context means: helping n parties to keep a secret
that means, all of the original n parties share the common interest of keeping that secret ...
in your case, you suspect at least one of the parties not to share this interest ... this is where classical crypto attempts will fail to solve your problem ...
pay tv companies learned this the hard way ... their solution seemingly is to replace the content keys faster than a group of rouge actors can share the needed keys for live decryption and to manage access to the content keys by encrypting them with group keys, which are partitioned and distributet along all legitimate clients ... that only "works" (read "not really if you put in enough effort") for large dynamic content streams, not for a static file ...
your use case sounds more like digital watermarking and fingerprinting
This is a question about whether my security process is adequate for the kind of information i am storing.
I am building a website using ASP.NET 4.0 with a SQL backend and need to know how my security would hold up with regards to passwords and hashes etc.
I don't store any critical information on someone - No real names, addresses, credit card details or anything like that... just email and username.
For now, I am deliberately leaving out some specifics as I am not sure if telling you them will weaken my security but if not I can reveal slightly more.
Here is how I do it:
The user registers with their email and a unique username up to 50 chars long
They create a password (minimum 6 chars) using any characters on the keyboard (I HTMLEncode the input and am using parameterized stored procedures so I don't restrict the chars)
I send them an email with a link to verify they are real.
I use FormsAuthentication to set an auth cookie but I'm not using SSL at the moment... I understand the implications of sending auth details across plain http but I have asked my host to add the cert so it should be ready shortly.
It's the hashing bit I need to be sure of!
I create a random 100 character salt from the following char set (I just use the System.Random class, nothing cryptographic) - abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNOPQRSTUVWXYZ0123456789!£$%^*()_{}[]#~#<,>.?
This is then merged with the password and then hashed using SHA-512 (SHA512Managed class) tens of thousands of times (takes nearly 2 seconds on my i7 laptop to generate the final hash).
This final hash is then converted to a base64 string and compared with the already-hashed password in the database (the salt is stored in another column in the DB too)
A few questions (ignore the lack of SSL for the moment, I just haven't bought the certificate yet but it will be ready in a week or so):
Does this strike you as secure enough? I understand there are degrees of security and that given enough time and resources anything is breakable but given that I don't store critical data, does it seem like enough?
Would revealing the actual number of times I hash the password weaken my security?
Does a 100 character salt make any difference over, say, a 20 character one?
By revealing how I join a password and salt together, would that weaken my security?
So, let's try to answer your questions one by one:
Does this strike you as secure enough? I understand there are degrees of security and that given enough time and resources anything is breakable but given that I don't store critical data, does it seem like enough?
No. It is definitely not "secure enough".
Without seeing code, it's hard to say more. But the fact that you're doing a straight SHA512 instead of doing a HMAC indicates one problem. Not because you need to be using a HMAC, but because most algorithms that are designed for this purpose use HMAC under the hood (for several reasons).
And it seems likely you're doing hash = SHA512(hash) (just from your wording) which is proven to be bad.
So without seeing code, it's hard to say for sure, but it's not pointing in the right direction...
Would revealing the actual number of times I hash the password weaken my security?
No, it shouldn't. If it does, you have a problem somewhere else in the algorithm.
Does a 100 character salt make any difference over, say, a 20 character one?
Nope. All the salt does is make the hash unique (forcing the attacker to attack each password separately). All you need is a salt long enough to be statistically unique. Thanks to the Birthday Problem, 128 bits is more than enough for a 1/10^12 chance of collision. Which is plenty for us. So that means that 16 characters is the upper bound on salt effectiveness.
That doesn't mean it's bad to use a longer salt. It just means that making it longer than 16 characters doesn't significantly increase the security it provides...
By revealing how I join a password and salt together, would that weaken my security?
If it does, your algorithm is severely flawed. If it does, it amounts to Security Through Obscurity.
The Real Answer
The real answer here is to not re-invent the wheel. Algorithms like PBKDF2 and BCRYPT exist for exactly this purpose. So use them.
Further Information (Note that these talk about PHP, but the concepts are 100% applicable to ASP.NET and C#):
YouTube Video - Password Storage and Hacking in PHP
Blog Post - The Rainbow Table Is Dead
Blog Post - Properly Salting Passwords
PHP password_hash RFC
Blog Post - Seven Ways To Screw Up BCrypt
In theory, your hashing scheme sounds ok. In practice, it sounds like you have rolled your own crypto, which is bad. Use bcrypt, scrypt, or pbkdf2. All of these are designed by security professionals.
Not really, but I don't think anyone needs to know that anyway.
No. It just needs to be unique to every user. The purpose of salt is to prevent precalculation of hashes/rainbow table attacks.
This doesn't apply once you make use of bcrypt (or scrypt or pbkdf2)
http://security.stackexchange.com has some topics on the subject, you should check them out.
Some extra notes - serious attackers will crack sha512 hashes way faster than your laptop. For example you could rent a server with a few Tesla GPU's from Amazon or similar, and start cracking at a few billion hashes/second rate. Scrypt makes some effort trying to prevent this by using memory intensive operations.
6 characters minimum for password is not enough, go with at least 8. A related image, I haven't verified the times but it gives a rough estimate and gives you the general idea (excluding dictionary attacks, which can target longer passwords):
I currently perform penetration testing of ASP.NET application and trying to exploit Padding Oracle Attack. This AFAIK is based on response code analysis, but both ScriptResource and WebResource axds of the system under test always respond with 200 OK, even if cipher has been invalid. In this case, however, the content of the response is an empty string.
Is it possible to use any of the axd as the oracle in this case? Maybe basing on response content difference.
The Padding Oracle Attack works by being able to distinguish between two cases:
The server failed to decrypt the data because, upon decryption, it did not found a properly formatted padding.
The server found a correct padding, but the decrypted data turned out to be random junk.
There may be several ways for an attacker to get such a distinction. A specific error code from the server is just the easiest to exploit; but any detectable difference is enough. The attack was first published in 2002 (yes, it took 8 years for people to notice that it could be applied to ASP !) and it has been demonstrated on a SSL connection with only a timing difference: the server was decrypting the data, and then was verifying the MAC only if the decryption went fine; the extra 2ms taken by the MAC computation were enough for the attacker to know whether the padding was valid, allowing for direct application of the Padding Oracle Attack.
To answer your original question, the content length can be used. Padbuster notes the status code but I think it detects entirely off the response length.
To answer your reply to Troy, a long ciphertext length does not indicate they are vulnerable. Typically a short ciphertext length does indicate they are vulnerable, but you need to dot net url decode the value then see if modulus 8=0 to see if it's vulnerable. In other words, the length will be a multiple of 8. Usually i'll see one block of ciphertext (16 bytes) end up about 25 bytes once it's dot net url encoded. The fix includes a HMAC (I think), which extends the length and should make one block cipertexts impossible. I can't say this with certainty, as I'm not sure how long the HMAC is and if it works after padding or not.
It sounds to me like the padding oracle patch may have been installed and as a result you're not getting the error codes you were expecting. Have a look at Do you trust your hosting provider and have they really installed the padding oracle patch and see if you can establish this.
We've had to extend our website to communicate user credentials to a suppliers website (in the query string) using AES with a 256-bit key, however they are using a static IV when decrypting the information.
I've advised that the IV should not be static and that it is not in our standards to do that, but if they change it their end we would incur the [big] costs so we have agreed to accept this as a security risk and use the same IV (much to my extreme frustration).
What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.
*UPDATE:*We are also using the same KEY throughout as well.
Thanks
Using a static IV is always a bad idea, but the exact consequences depend on the Mode of Operation in use. In all of them, the same plaintext will produce the same ciphertext, but there may be additional vulnerabilities: For example, in CFB mode, given a static key, the attacker can extract the cipherstream from a known plaintext, and use it to decrypt all subsequent strings!
Using a static IV is always a bad idea. Using a static key is always a bad idea. I bet that your supplier had compiled the static key into their binaries.
Sadly, I've seen this before. Your supplier has a requirement that they implement encryption and they are attempting to implement the encryption in a manner that's as transparent as possible---or as "checkbox" as possible. That is, they aren't really using encryption to provide security, they are using it to satisfy a checkbox requirement.
My suggestion is that you see if the supplier would be willing to forsake this home-brewed encryption approach and instead run their system over SSL. Then you get the advantage of using a quality standard security protocol with known properties. It's clear from your question that neither your supplier nor you should be attempting to design a security protocol. You should, instead, use one that is free and available on every platform.
As far as I know (and I hope others will correct me if I'm wrong / the user will verify this), you lose a significant amount of security by keeping a static key and IV. The most significant effect you should notice is that when you encrypt a specific plaintext (say usernameA+passwordB), you get the same ciphertext every time.
This is great for pattern analysis by attackers, and seems like a password-equivalent that would give attackers the keys to the kingdom:
Pattern analysis: The attacker can see that the encrypted user+password combination "gobbbledygook" is used every night just before the CEO leaves work. The attacker can then leverage that information into the future to remotely detect when the CEO leaves.
Password equivalent: You are passing this username+password in the URL. Why can't someone else pass exactly the same value and get the same results you do? If they can, the encrypted data is a plaintext equivalent for the purposes of gaining access, defeating the purpose of encrypting the data.
What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.
A good example of re-using the same nonce is Sony vs. Geohot (on a different algorithm though). You can see the results for sony :) To the point. Using the same IV might have mild or catastrophic issues depending on the encryption mode of AES you use. If you use CTR mode then everything you encrypted is as good as plaintext. In CBC mode your first block of plaintext will be the same for the same encrypted data.
I'm looking for a simple encryption tutorial, for encoding a string into another string. I'm looking for it in general mathematical terms or psuedocode; we're doing it in a scripting language that doesn't have access to libraries.
We have a Micros POS ( point of sale ) system and we want to write a script that puts an encoded string on the bottom of receipts. This string is what a customer would use to log on to a website and fill out a survey about the business.
So in this string, I would like to get a three-digit hard-coded location identifier, the date, and time; e.g.:
0010912041421
Where 001 is the location identifier, 09 the year, 12 the month, and 04 the day, and 1421 the military time ( 2:41 PM ). That way we know which location the respondent visited and when.
Obviously if we just printed that string, it would be easy for someone to crack the 'code' and fill out endless surveys at our expense, without having actually visited our stores. So if we could do a simple encryption, and decode it with a pre-set key, that would be great. The decoding would take place on the website.
The encrypted string should also be about the same number of characters, to lessen the chance of people mistyping a long arbitrary string.
Encryption won't give you any integrity protection or authentication, which are what you need in this application. The customer knows when and where they made a purchase, so you have nothing to hide.
Instead, consider using a Message Authentication Code. These are often based on a cryptographic hash, such as SHA-1.
Also, you'll want to consider a replay attack. Maybe I can't produce my own code, but what's to stop me from coming back a few times with the same code? I assume you might serve more than one customer per minute, and so you'll want to accept duplicate timestamps from the same location.
In that case, you'll want to add a unique identifier. It might only be unique when combined with the timestamp. Or, you could simply extend the timestamp to include seconds or tenths of seconds.
First off, I should point out that this is probably a fair amount of work to go through if you're not solving a problem you are actually having. Since you're going to want some sort of monitoring/analysis of your survey functionality anyway, you're probably better off trying to detect suspicious behavior after the fact and providing a way to rectify any problems.
I don't know if it would be feasible in your situation, but this is a textbook case for asymmetric crypto.
Give each POS terminal it's own private key
Give each POS terminal the public key of your server
Have the terminal encrypt the date, location, etc. info (using the server's public key)
Have the terminal sign the encrypted data (using the terminal's private key)
Encode the results into human-friendly string (Base64?)
Print the string on the receipt
You may run into problems with the length of the human-friendly string, though.
NOTE You may need to flip flop the signing and encrypting steps; I don't have my crypto reference book(s) handy. Please look this up in a reputable reference, such as Applied Cryptography by Schneier.
Which language are you using/familiar with?
The Rijndael website has c source code to implement the Rijndael algorithm. They also have pseudo code descriptions of how it all works. Which is probably the best you could go with. But most of the major algorithms have source code provided somewhere.
If you do implement your own Rijndael algorithm, then be aware that the Advanced Encryption Standard limits the key and block size. So if you want to be cross compatible you will need to use those sizes I think 128 key size and 128, 192, 256 key sizes.
Rolling your own encryption algorithm is something that you should never do if you can avoid it. So finding a real algorithm and implementing it if you have to is definitely a better way to go.
Another alternative that might be easier is DES, or 3DES more specifically. But I don't have a link handy. I'll see if I can dig one up.
EDIT:
This link has the FIPS standard for DES and Triple DES. It contains all the permutation tables and such, I remember taking some 1s and 0s through a round of DES manually once. So it is not too hard to implement once you get going, just be careful not to change around the number tables. P and S Boxes they are called if I remember correctly.
If you go with these then use Triple DES not DES, 3DES actually uses two keys, doubling the key size of the algorithm, which is the only real weakness of DES. It has not been cracked as far as I know by anything other than brute force. 3DES goes through des using one key to encrypt, the other to decrypt, and the same one to encrypt again.
The Blowfish website also has links to implement the Blowfish algorithm in various languages.
I've found Cryptographic Right Answers to be a helpful guide in choosing the right cryptographic primitives to use under various circumstances. It tells you what crypto/hash to use and what sizes are appropriate. It contains links to the various cryptographic primitives it refers to.
One way would be to use AES - taking the location, year, month, and day - encoding it using a private key and then tacking on the last 4 digits (the military time) as the inversion vector. You can then convert it to some form of Base32. You'll end up with something that looks like a product key. It may be too long for you though.
A slight issue would be that you would probably want to use more digits on the military time though since you could conceivably get multiple transactions on the same day from the same location within the same minute.
What I want to use is XOR. It's simple enough that we can do it in the proprietary scripting language ( we're not going to be able to do any real encryption in it ), and if someone breaks it, they we can change the key easily enough.