Slashdot Mirror
New Crypto Attack Affects Millions of ASP.NET Apps
Trailrunner7 writes "A pair of security researchers have implemented an attack that exploits the way that ASP.NET Web applications handle encrypted session cookies, a weakness that could enable an attacker to hijack users' online banking sessions and cause other severe problems in vulnerable applications. Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications."
This is /. aren't you supposed to say "What a surprise, .NET has flaws!" ?
No wit here.
I never could find how session ids were generated, suffice to say I didn't trust MS to implement them properly.
I ended up rolling my own session management in "old asp" using a COM wrapper to crypto api for access to the RNG + hashing functions, and allowed for a SQL backend, so we could run load-balanced servers and still have a session. I would do an application-key hmac on the output of the RNG (which I also didn't trust), concatenated with a knowable, sequential, unique part.
I don't use ASP anymore.
Just give us the exploit!
>If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.
This is one reason you should send user friendly error messages to your consumers instead of stack traces, stack traces can contain details that an attacker could use against you. It sounds like you're safe if you're following best practices already.
roll your own at the lowest possible layer. anything else and you're leaving your chin open.
When will MS release a patch for this? This could be really, really bad. I think it still requires that an attacker capture a cookie in order to steal the session, but not totally sure about that?
Anyone know just how serious this is?
What a surprise, encryption has flaws!
RTFA. It's not about flaws in encryption. It's about "ASP.NET's implementation of AES has a bug in the way that it deals with errors when the encrypted data in a cookie has been modified"
So it's the ASP.NET AES implementation that has flaws. The problem seems to be that the errors reveal enough information about how to decrypt the data.
This is /. aren't you supposed to say "What a surprise, .NET has flaws!" ?
No, no, no ... you're supposed to say "this doesn't affect Linux". But does it affect Mono?
Will more of the script kiddie hacking packages have "hardcore" venomous snake related names and graphics(ASCII for the l33t) or "hilarious" anal violation pun derived ones?
Recently I reviewed code of a colleague.
"Q: Why does the app store authorization i cookies?"
"A: But it's encrypted!"
Only a idiot would store "important stuff" in cookies. It's only a matter of time to break it.
What a surprise, encryption has flaws!
Nope, the cryptography is still flawless. ASP.NET just failed to use it correctly. AES-CBC would be perfectly secure if they used MAC to authenticate the data. MACs have been a critical part of crypto protocol design since the "DES ages" and padding oracle attacks have been known since 2002.
Just like RC4 is still secure if used properly, but WEP is broken due to protocol flaws (the problems with RC4 were known before WEP was designed).
So kids, make sure you always use MAC with your ciphers.
TFA has a bizarre idea of a "100% reliable" attack:
"It's worth noting that the attack is 100% reliable, i.e. one can be sure that once they run the attack, they can exploit the target. It's just a matter of time."
By that logic, this attack is 100% reliable against (web platform of your choice) too.
Beyond that, this attack requires fairly verbose error messages be sent back to the user of a web application. While I'm sure there do exist some ASP sites where this is the case, I don't think it has been in any of the non-intranet sites I've seen in my career.
It just is not standard in any exposed web site, especially the kind of web site where you would care about customer information getting out, to allow useful error messages reach the end user. It is by far the standard to catch the exceptions, log them on the server, and show the end user a generic error message which would not be helpful in the case of this exploit.
Who the hell is dumb enough to send "unfriendly" error messages in the first place???
The only time you send stack traces is when your site is in pre-production/development phases.
"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. The attacker may also be able to create authentication tickets for a vulnerable Web app and abuse other processes that use the application's crypto API."
Anyone storing these things in a cookie, regardless of encryption, needs to step away from the keyboard and stop developing web applications.
This is a non-issue as long as you realize that what is encrypted can be decrypted and keeping that in mind when you store information in a cookie.
ASP.NET uses a hashed message authentication code by default. So not sure what point you are trying to make by talking about them as a solution.
Source: see 'protection' at http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx
Sadly, many many people.
Seems to be more of a problem with the web application and less of ASP.NET. I mean, sure you can get the encryption key to the cookies, but seriously who puts information like a bank balance or a social security number in a cookie anyway? You should have that stored server-side and only use a session id.
The first part of the presentation introduces the audience to Padding Oracle Attacks, the cryptographic concepts of the vulnerability, and finally how to exploit it. We also describe the algorithms implemented in POET (Padding Oracle Exploit Tool). POET is the free tool that we released a few months ago which can automatically find and exploit Padding Oracle vulnerabilities in web applications. The second part presents a previously unknown advanced attack. The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API! Finally we demonstrate the attacks against real world applications. We use the Padding Oracle attack to decrypt data and use CBC-R to encrypt our modifications. Then we abuse components present in every ASP.NET installation to forge authentication tickets and access applications with administration rights. The vulnerabilities exploited affect the framework used by 25% of the Internet websites.The impact of the attack depends on the applications installed on the server, from information disclosure to total system compromise.
http://ekoparty.org/juliano-rizzo-2010.php
In soviet russia the government regulates the companies.
And all the paid MS astroturfing fanbois started singing in choir the monocrop argument. Uh, no... Wait : .net is not the most successful platform for webapp. Darn. The monocrop fallacy ain't working this time, need to find another fallacy.
I'm going to be a crypto pedant here for a moment. Don't use the words "perfectly secure" to refer to any cryptographic scheme other than a true one-time pad. The phrase "perfect security" has a *very* specific meaning in cryptology, defined by C. E. Shannon, and the only thing that meets the definition is a true one-time pad (a symmetric key that is perfectly random - the odds of any particular bit in the string being 1 are exactly 50% - and longer than the message it encrypts and is only used for that one message).
AES is extremely secure (no one who publishes has found a practical attack against it that's easier than brute force, and all the best cryptanalysis folks who publish have been trying since the original submission of Rijndael for the AES contest), but it cannot be "perfect" - because a brute force attack will work. Even a brute force attack won't work against a one-time pad.
Stack dumps make me look smart. Chics dig stack dumps.
Even one time pads are susceptible to brute force attacks.
The only way you can make the assertion that they are not is to assume the original message was simply random characters, with no obvious language.
If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.
Sig Battery depleted. Reverting to safe mode.
I don't generally bother storing anything in a cookie if I can avoid it. There are simply better ways to do things IMHO.
On the other hand, if this will allow someone to spoof an asp.net user session (rather than a roll your own authentication system) then I may be in trouble.
Of course if it needs a verbose error in order to work, I'm fine. FriendlyError.aspx doesn't show stack traces.
Which human readable text? The point of trying to brute force a one-time pad encoded message (without having access to the pad itself) is that any message of the same length is just as possible. How do you determine the actual message from all of the other possible messages of the same length?
For every plaintext of given length and every 1TP ciphertext of the same length there is a trivially obtainable 1TP key that converts the latter into the former.
I immediately thought, "how would you even snip some one else's cookie in the first place"? Unless the site was not using SSL and you sniffed it off an open WiFi connection. Maybe this is what they meant by "side channels".
Copied this comment from "asmx86" on the TFA's talkback comments:
Totally useless. If you can sniff in realtime then you can already hijack their session which means accessing the site with user's credential.
So, what they discovered is that you can crack the content of this and see whats in it - which means the application itself must SAVE in these cookies important data, maybe stupid programmers do that - the way to do it is just using the session id and save data server side.
Besides all this, all banks in the world use SSL - try to break that...
Anyway, good research but too much smoke if you know what I mean.
Even one time pads are susceptible to brute force attacks.
This is outright wrong. If it's susceptible to brute force attacks, it's not a one time pad.
Reason being, if you don't know the key, you can decrypt a one-time-pad to produce any possible message by appropriately changing the key.
This is also how OTP can provide deniable encryption: if you have the ciphertext, you can construct another OTP key that decrypts to totally different material, at your choice.
Cmon!
1) HTTP over SSL - sniff and BREAK that.
2) Important information in the cookies? That person should not be called programmer.
So maybe, MAYBE.. you could apply this to i-want-to-make-this-conference-very-popular-selling-some-smoke-yay.com.ar - thats it.
Whats the big deal here? Good research, sure.. too much SMOKE to publicity some mid-lame conference (Mid basically, there is some very intelligent people at it, wonder why...)
Any message being possible only makes sense when you define "and message" to include total nonsense strings of text.
You can use the 5th grade test to see if your brute force attack worked.
Had the output to a 5th grader, and if can read it out loud your brute force worked.
If I handed you two messages:
1) The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month.
--and ;werj ;kljr;qijaof; ;ileurie;oir;iw;; ;lekjeri ;wkrie9jg; ;'keroje;kj ;wljejrei ioj;akjie;titj ww';ler;lj e;kerjw
2) aljkhwerh;lkjerja;ke
Which one of those would your 5th grader choose?
Sig Battery depleted. Reverting to safe mode.
Any possible message is far from any reasonable message. A random sting of characters is not the sort of thing people encrypt.
Try to put this in real world terms here, and stop being such a pendant.
Sig Battery depleted. Reverting to safe mode.
"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. "
Respectfully, are you sure you understand how a one-time pad works?
Attempting to brute force a one-time pad is as likely to produce a third option:
3) The account numbers to the secret Swiss Bank account are 3435464482 and 363578345. Please do not access the accounts more than once a month.
as your #1. In other words, the same message with totally different account numbers. Or any other message of the same length.
I don't think you're getting it.
Brute forcing a one time pad makes "The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month." just as likely as "The account numbers to the secret Swiss Bank account are 123456789 and 987654321. Please do not access the accounts more than once a month." and you have no way of telling which one was the original message.
if the original was normal human readable text it becomes immediately obvious when your brute force succeeds
You will get any possible message of the same length, including several normal human readable ones. Barring having other information, there isn't any way to determine which one is the actual message. For example, if you have a 28 character message, attempting to brute force the OTP it will give you both of the results below, both equally plausible, along with many others which are equally plausible.
meeting canceled, stay home.
meeting at 10:00, room 1103.
upon the advice of my lawyer, i have no sig at this time
Eh nevermind just ignore my post, I just saw your other 'pendant' comment; you have to be a troll.
I'm pretty sure this .NET is server-side.
I don't think you know how a one time pad works - trying to brute force a one time pad will yield both "The account numbers to the secret swiss bank account are 12345 and 67890" and "The killer is staying in the Slashdot hotel, room number 1235", along with literally every permutation of letters and numbers (or whatever you're encrypting) that can be possibly produced. The only attacks against OTP are side attacks, against things such as your random number generator and transmission of the key.
According to government statistics, if you mean 5th graders here in the US, they wouldn't be able to read either one.
Even one time pads are susceptible to brute force attacks.
Nope, absolutely incorrect. That's what makes one-time pads different. When the key length is the same as the plaintext length, it is possible have perfect security. Look up unicity distance.
If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.
But your brute force attack will yield every single possible plaintext (with the same length as the original plaintext). Which is the real one?
For example, if the ciphertext is BWIJAA, your brute force attack will get ATTACK for one key, and GOHOME for another. (And every other 6 character string.)
If the geiger counter does not click, the coffee, she is not thick.
Try not to be ignorant, not to say idiotic. "Any possible message" includes "any reasonable message". Come back when you understand Shannon's theorem.
So kids, make sure you always use MAC with your ciphers.
There are actually a couple of things that people should probably generally know:
http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
http://rdist.root.org/2010/09/10/another-reason-to-mac-ciphertext-not-plaintext/
And as for MACs: don't try to roll your own, but use HMAC. Doing a simple (m = plaintext, k = key) solution as on of the following
H(k || m)
H(m || k)
is not secure even though many people think they are "salting" things with a key of some kind:
http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/
Would any message of the same length make sense?
Sig Battery depleted. Reverting to safe mode.
Basically, the problem here is that ASP.NET leaks information about incorrectly decrypted data. If the attacker can get information about the failed decryption, then that's called an oracle. The secure way to handle any sort of decryption error is simply to say "decryption error", regardless of whether it's a padding error, a MAC (message authentication code) error, invalid plaintext, or whatever. You should never give the user the invalid decrypted data or any information about it.
Some SSL/TLS implementations have this problem, too, because they treat a MAC error differently than other decryption errors. Secure implementations, including OpenSSL, have the sane behavior: simply stating that the decryption failed.
A good way to make padding oracle attacks irrelevant is to design protocols to use cipher modes that don't require padding. In other words, instead of using CBC, use CFB. This does have some tradeoffs, but overall CFB is a good choice. (For example, OpenPGP uses CFB.)
And that is why you are fated to die a virgin
I know exactly how a one time pad works. EXACTLY. Stop asking the question.
Brute force attacks yield mountains of garbage, and a few nuggets of highly probable deciphers, of which usually only one makes language and contextual sense.
Sig Battery depleted. Reverting to safe mode.
You are being pedantic. He clearly means any sensical message of the same length. Which makes one time pads more secure as the message length increases (provided the key size is still longer than the message).
I know exactly how a one time pad works.
No you don't, if your posts on the subject are anything to go by.
I don't think you have a clue how a one time pad works, based on your comments here. You can make the message "qwerty iopas fghjkl xcvbn qwertyui" decrypt to anything which has the same length, so you could get something like "The attack will happen this Monday" AND "The attack will happen this Friday" AND "icebike does not understand OTPs!!"
Any, no. But certainly there are many, many messages of the same length that would make sense.
To put it another way, let's say a /. sig is 120 characters (I don't know the exact number offhand) and that a million /. users have sigs, all of which are different and make some kind of sense. If I encrypt one with a one-time pad, there's no way for you, using brute force, to figure out which user's sig it is -- each of those million possibilities (and many, many more) would appear equally possible to your best discernment.
You're saying that as long as you come up with a message that looks like words and forms a sentence that's the right length, you've successfully brute forced the pad. That's not remotely the case.
Actually the implementation and use of AES in the ASP.NET framework is fine.
Websites that aren't trapping internal exceptions are bugged.
The problem here is the developer using the code who isn't catching the exception, and worse still allows it to pass through directly to an untrusted 3rd party (the user).
Its not an ASP.NET bug if you proceed to print the password on the screen when users attempt to login, this really isn't any different. The dev using the ASP.NET framework is using it wrong.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
a pendant is something that hangs, for example a locket hanging from a chain.
Did you mean to say pedant? http://en.wikipedia.org/wiki/Pedant. Oh, whoops - guess I was a pedant...
Often it's repeated that programmers should not implement their own crypto libraries. I've been considering writing and public-domaining a cyrpto library front-end (an API library) that itself takes back-end plug-ins to implement stream/block cipher (or stream cipher AES ... basically a PRNG with a fixed IV having its output AES encrypted, and using the stream as a keystream i.e. XOR vs plaintext to make one-time-pad). Yes, there's crypto libraries now; but mine would explicitly have code and documentation explaining the mitigation mechanisms for algorithmic flaws and other implementation details that avoid brokenness.
The point here would be 1) to implement non-flawed algorithms (i.e. AES) in a documented, non-flawed way; and 2) to implement flawed algorithm mitigation.
For example, with RC4 you can statistically discover key bytes with weak IVs. In WEP the attacker assumes the first byte is 0xAA; then, for 24 bit IVs, all he needs is an IV (a+3, n-1, X) key index (a), element space (n), and any X. With 8 bit elements (1 byte at a time), this is n=256.
To mitigate this, make sure (n) never equals (256); also making sure (a) never equals 3 will prevent the attacker from figuring out the first word of the key, which is needed to find the second (which you need to find the third etc.), totally eliminating the starting point. This means you can theoretically allow (a!=3,n-1=255,X) or (a=3,n-1!=255,X) and be secure. If you simply leave (n-1!=255), you eliminate 0.0056 bits of the 24 bit IV; if you leave (a!=3) as well, you eliminate 0.011 bits. If you eliminate the initialization case (3,255,X), you only lose 1.7 x 10^-7 bits; however, if the attacker knows/can guess the second byte of the WEP header, your security falls again.
The best security for RC4 is to just ban (n-1=255), leaving 23.994 bit IVs instead of 24 bit IVs. If other weak conditions are present, we'll also examine their cases and detect/alter them as well. Of course, you can't just make n-1=255 imply n-1=254; instead, generate a random value between 1 and 254. If you think that generating a random 8 bits is faster, then have a custom get_random_RC4_IV() that does that and, failing that, subtracts a random value between 1 and 255 when it encounters n-1=255.
All encryption algorithms implemented for that library would be implemented and documented as such. Here's the attack. Here's the conditions. Here's the conditions we can eliminate. Here's the impact on entropy. Here's other considerations. Here's what considerations we ignore and why. Here's our final implementation plan and why we feel it's optimal. Here's the impact on entropy.
And that is why YOU shouldn't be writing your own AES implementation, or whatever else.
Support my political activism on Patreon.
*Boggle*
Really?
Let's try an experiment since you seem too thick to understand this. Here is my encrypted message:
zxc
I'll give you a hint that the clear text is an English word, and the one-time pad used to encrypt it used only letters (so we're talking modulo 26 addition here). This means that there are 17,576 one time pads I could have used.
You're right that the vast majority of those one-time pads can be eliminated, because they give garbage decrypted text. Among these would be:
abc, ujc, asd, qwe
Applying these one-time pads to the cipher text is left as an excersize to the reader.
However, there is a large subset of the 17,576 possible one-time pads that produce readable clear text, among them:
fpy, rwi, yco
which respectively decrypt the cipher text to:
the, hat, bum
Can you tell which was the real clear text? No you can't. And for longer messages you can't tell between 'Bill ate the cat' and 'Bill fed the cat.' from a cipher text of 'era and qwe omn' because there is a possible one-time pad for each.
Another way is to look for known source code keywords. You can start by looking for code that imports low level cryptography libraries such as:
.NET: .NET Cryptography, Microsoft CryptoAPI
C/C++: OpenSSL, Crypto++
Python: PyCrypto, M2Crypto
Java: Java Crypto Extension, BouncyCastle
Then look for routines that perform encryption and decryption. If there’s some code to handle error while decrypting, and/or no sign of MAC usage, then it’s high probability you have found a target for the Padding Oracle attack. Regardless of which method one uses, the most important thing is to analyse and understand the meaning of error messages returned by the target upon receiving mangled ciphertexts. In short, you need to know when the padding is VALID, and when it’s INVALID.
It has been shown that E&A (encrypt & authenticate) is inherently insecure: http://www.cryptopp.com/wiki/Authenticated_Encryption. And this is is exactly the scheme used by ASP.NET
So kids, make sure you always use MAC with your ciphers.
Yes, I've always been a big proponent of MAC and c.
OK. You don't get it. Let me try and explain it a little bit better - admittedly, the other explanations are a bit lacking.
A one time pad is an encryption key of the same length as the original message. For a 15 character message, I need a 15 character pad. But I can construct a pad to give me *every single message of length 15*. So I have no way of figuring out which one it is, because I can make it say *anything*, as long as the length is right.
So I could try and brute-force a message of length 10, but I'd be able to "decrypt" every word and phrase of length 10.
*This* is why OTP is the only 'secure' encryption - it's precisely because the tumblers on our virtual lock never fall into place, since they often do anyways.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
This presumes you can get the proper plaintext determined that way.
With a one-time pad, you're talking about something where you can conceivably get "intelligible" content and it could be the message with chaff around it- or it could be a false positive. Unless you know the plaintext from before it was encoded (along with any chaff measures you might have applied to the selfsame...)- you can't be sure you've got the message.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Not to mention, it's just as likely as "The president will be delivered at the drop-off location at precisely 0400 hours. He then will be transported to a secure, hidden facility."
No comment.
To be fair with sufficently trivial messages and enough knowledge of the context SOME one time pads can be brute forced.
Your example shows why in practice they cannot. However If the message is "Meet me at sunrise", and I happen to know that the message was intended to convey a meeting time as well as be familiar with the typical speech patterns of the sender, I'm much more likely to be able to crack that.
However in all cases this pretty much applies: http://xkcd.com/538/
You do realize that there's no exploitable pattern in a proper OTP, yes?
This means that for a sufficiently long OTP encrypted text, both your comment and my comment look like "valid" decryptions. As are bomb making instructions, the menu for Obama's dinner last night, whatever your password to /. is, and the combination to your bank's vault.
I forget what 8 was for.
They do use a MAC by default since ASP.NET 2.0. You'd have to turn it off for an attack to work.
How can such a low ID say such nonsense. You sir are a shame to our kind.
With an OTP you will also find a key that says:
I can't meet today
The question is when you're going to post the one time pad to decrypt the messages you've posted in this thread, as the cipher text is nothing but complete nonsense.
How about if I hand you a third message reading "The account numbers to the secret Swiss Bank account are 7846268231 and 532783502. Please do not access the accounts more than once a month.". It's just as likely with yet another brute forced key. So is "The deal is off. I don't know what I was thinking" with some null padding at the end. So is "Hello, would be code breaker, don't you wish I would re-use my OTP?".
Now which one will the 5th grader choose?
Right because C# stupidly does not support checked exceptions like Java.
No, it yields every possible message of that length (including shorter messages padded out with spaces or zeros). You may be thinking about polyalphabetic cyphers where the key is shorter than the message. In a one time pad, the key is as long or longer than the message. It even yields LONGER messages in LZW compressed form.
There is no way to choose between "attack at dawn" and "attack at noon" or even "don't attack!!" for example. They are all equally probable.
Of course, .NET runs on wishes and sparkles, not servers like other programming languages. You do realise you can run ASP.NET apps on Linux too, right?
As we've seen with Windows etc, stick with just as good off the beat frameworks.
Ooh! Ooh! Wishes and sparkles, just like the iPad!
Has nothing to do with checked exceptions, and everything to do with turning on development-mode error messages on production websites...
Karma: Poor (Mostly affected by lame karma-joke sigs)
MAC = Message Authentication Code, prevents a client from forging a valid value. You can think of it like a digital signature, except that it’s much faster and the same key creates and verifies the data - which is perfect when your web app generates, sends the value to the client, receives the value from the client, and wants to verify that it is the same thing it sent originally (i.e. hasn't been changed/forged).
Given an oracle, this vuln does make decrypting a token – and thus getting the plaintext – O(n), instead of O(2^n) as brute force would dictate. It doesn’t require plaintext, just a ciphertext, and the attack finds the plaintext a byte at a time, from the end. From skimming it, it seems their paper doesn’t actually describe the attack (see below), but rather just describes how to test for the presence of the vulnerability.
Anyway, the oracle condition typically occurs when you hand something to the client and check it later, which is really a sign you should be using MAC (specifically HMAC). You can also use encryption if you want to hide the value, but for random nonces and session IDs, it doesn’t usually matter (doesn’t hurt, either). You’ll want to encrypt-then-MAC if you do both.
Background knowledge necessary for the attack:
PKCS#5 padding is: If your input is a multiple of the block length, add a full block of padding. Otherwise, add enough octets to pad to a block length. Each octet of the pad always has the number of octets of padding used. So for example, the plaintext ALWAYS ends in 01, or 02 02, or 03 03 03, etc.
In CBC mode: flipping bits in the previous ciphertext block flips the same bits in the next plaintext block after decryption. See my paper[1] for a pretty picture.
Attack
Suppose your plaintext ends in 04 04 04 04. If I twiddle the last octet of the (previous block of) ciphertext, only one value will give valid padding in the plaintext – 01. Now I fix the last octet to 02 (by flipping the two least significant bits), and go to work on the previous octet, trying to make the plaintext end in 02 02.
As a side effect, if I know what bits I had to flip to get the valid padding values, I know that your plaintext differs from the valid padding value in exactly those bits. But the real problem is that the only thing between me and a valid plaintext is this padding (and the vagaries of your block cipher mode). It's like using a screwdriver when you should be using a hammer. You'll see this over and over again in crypto; "use things for what they are designed", or "only rely on the actual security guarantees of your primitives".
Extra credit:
[1] http://www.subspacefield.org/security/web_20_crypto/ - the premise of which could have been "you probably want to use MAC, not encryption"
[2] http://www.subspacefield.org/security/security_concepts.html - for crypto-related reading (I'll put this description in there shortly)
Sometimes, yes. This is what gives the one-time pad its strength.
I have no problem with the fact that these guys found the exploit or that they disclosed the exploit publically. My problem on this is that they disclosed it publically before disclosing it to the vendor. the result is a potential 0 day attack. Now potentially million of man hours will be wasted because this weekend and during this coming week all around the world. As I understand it, this sxploit effects many different platforms, not just asp.net. These guys were wreckless. , unfortunately, some people will cheer them on and think that this is good
If I handed you two messages:
1) The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month.
--and 2) aljkhwerh;lkjerja;ke ;werj ;kljr;qijaof; ;ileurie;oir;iw;; ;lekjeri ;wkrie9jg; ;'keroje;kj ;wljejrei ioj;akjie;titj ww';ler;lj e;kerjw
Which one of those would your 5th grader choose?
The problem was you would be handing that 5th grader every single possible message. Look at it this way. Let's say you KNOW that the message says "Your PIN number is XXXX" with XXXX replaced by the actual PIN number. In most crypto systems you could brute-force the key used to encrypt the data by trying each one and testing the results against this string to see if it matches the correct format. If you go through every possible key, then one of the resulting strings contains the correct PIN number.
In a one-time pad you can immediately figure out the first 19 bytes of the pad because you know what the start of the message is. That doesn't do you any good however because you have absolutely no idea what the remaining 4 bytes of the pad are. And those first 19 bytes of the pad will never be used again in the current message or in any other (hence the one-time pad). The last four bytes of the pad are equally likely to be anything that would result in four digits given the encrypted text you received. The result of your "brute-force" attack would be 10,000 possible keys yielding 10,000 possible PIN numbers that all would match the encrypted message you received.
Congratulations, you used your knowledge of what the message must contain to tell you exactly what you already knew with no way to find out anything you don't already know.
Put another way, you can use whatever rules you would use to test that the resulting decrypted message was valid and generate the possibilities without ever looking at the message. In an example below let's say that you have three characters and you know they form a three letter word. You can either:
All produce the same results and are just as likely to be the correct text of the message. Trying to brute-force the actual message is no better than trying to brute-force random bytes.
Even one time pads are susceptible to brute force attacks.
The only way you can make the assertion that they are not is to assume the original message was simply random characters, with no obvious language.
If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.
Actually you can substitute random bytes for the message and your brute force will be equally successful. How does that help you tell what the message actually said?
It's true that they're susceptible to brute force attacks. However, the inability to know when you have the correct cipher makes it pointless. Yes, you can brute force the key, but because you don't know if it's the actual key or not, you have no way to know if you've succeeded. Simply being readable text doesn't mean anything because there are millions of other readable text pads that can come out of it.
My guess is that you don't really understand how the one-time pad works.
If you need web hosting, you could do worse than here
I'm all for .NET, I love how I can create a web service quickly, and I've been impressed to see how it has been quietly building up to a solid base, and there are folks building good apps around it like Roy Osherove's TypeMock, even though Rails gets all the fanfare. but fall in the middle for checked exceptions, having seen massively stupid apps with 2/3 of the code handling the exception in every method, and other apps turning an exception into an unchecked exception. Use them, with care.
The argument, way back when, against checked was, "we are good, smart programmers, don't treat us stupid, we will document the exceptions so if you should trap it (or turn off dev mode, or whatever the latest excuse is), you can, otherwise leave us alone." But then you have other folks out there, the lean developers, saying forget about documentation, just code it. (As an aside, I think the future will be massively un-maintainable web apps being tossed because the original developers have long gone, and unless you have an deep understanding like DHH, forget about figuring out the code, meanwhile well-document but dull C code will carry on)
The counter-argument, as proven by this very very very costly example is, a little reminder doesn't hurt.