Re: Banks Test ID Device for Online Security
Bill Stewart wrote: Yup. It's the little keychain frob that gives you a string of numbers, updated every 30 seconds or so, which stays roughly in sync with a server, so you can use them as one-time passwords instead of storing a password that's good for a long term. So if the phisher cons you into handing over your information, they've got to rip you off in nearly-real-time with a MITM game instead of getting a password they can reuse, sell, etc. That's still a serious risk for a bank, since the scammer can use it to log in to the web site and then do a bunch of transactions quickly; it's less vulnerable if the bank insists on a new SecurID hit for every dangerous transaction, but that's too annoying for most customers. in general, it is something you have authentication as opposed to the common shared-secret something you know authentication. while a window of vulnerability does exist (supposedly something that prooves you are in possession of something you have), it is orders of magnitude smaller than the shared-secret something you know authentication. there are two scenarios for shared-secret something you know authentication 1) a single shared-secret used across all security domains ... a compromise of the shared-secret has a very wide window of vulnerability plus a potentially very large scope of vulnerability 2) a unique shaerd-secret for each security domain ... which helps limit the scope of a shared-secret compromise. this potentially worked with one or two security domains ... but with the proliferation of the electronic world ... it is possible to have scores of security domains, resulting in scores of unique shared-secrets. scores of unique shared-secrets typically results exceeded human memory capacity with the result that all shared-secrets are recorded someplace; which in turn becomes a new exploit/vulnerability point. various financial shared-secret exploits are attactive because with modest effort it may be possible to harvest tens of thousands of shared-secrets. In one-at-a-time, real-time social engineering, may take compareable effort ... but only yields a single piece of authentication material with a very narrow time-window and the fraud ROI might be several orders of magnitude less. It may appear to still be large risk to individuals ... but for a financial institution, it may be relatively small risk to cover the situation ... compared to criminal being able to compromise 50,000 accounts with compareable effort. In some presentation there was the comment made that the only thing that they really needed to do is make it more attactive for the criminals to attack somebody else. It would be preferabale to have a something you have authentication resulting in a unique value ... every time the device was used. Then no amount of social engineering could result in getting the victim to give up information that results in compromise. However, even with relatively narrow window of vulnerability ... it still could reduce risk/fraud to financial institutions by several orders of magnitude (compared to existing prevalent shared-secret something you know authentication paradigms). old standby posting about security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion (was: SSL/TLS passive sniffing)
- Original Message - From: John Denker [EMAIL PROTECTED] Sent: Thursday, January 06, 2005 3:06 AM Enzo Michelangeli wrote: [...] If the PRNG uses a really non-invertible algorithm (or one invertible only with intractable complexity), its output gives no insight whatsoever on its internal state. That is an invalid argument. The output is not the only source of insight as to the internal state. As discussed at http://www.av8n.com/turbid/paper/turbid.htm#sec-prng-attack attacks against PRNGs can be classified as follows: 1. Improper seeding, i.e. internal state never properly initialized. 2. Leakage of the internal state over time. This rarely involves direct cryptanalytic attack on the one-way function, leading to leakage through the PRNGs output channel. More commonly it involves side-channels. 3. Improper stretching of limited entropy supplies, i.e. improper reseeding of the PRNG, and other re-use of things that ought not be re-used. 4. Bad side effects. There is a long record of successful attacks against PRNGs (op cit.). Yes, but those are implementation flaws. Also a true RNG could present weaknesses and be attacked (e.g., with strong EM fields overcoming the noise of its sound card; not to mention vulnerabilities induced by the quirks you discuss at http://www.av8n.com/turbid/paper/turbid.htm#sec-quirks). Anyway, I was not saying RNG's are useless because PRNG's are more than enough: the scope of my question was much narrower, and concerned the concept of entropy depletion. I'm not saying that the problems cannot be overcome, but the cost and bother of overcoming them may be such that you decide it's easier (and better!) to implement an industrial-strength high-entropy symbol generator. Sure, I don't disagree with that. As entropy is a measure of the information we don't have about the internal state of a system, That is the correct definition of entropy ... but it must be correctly interpreted and correctly applied; see below. it seems to me that in a good PRNGD its value cannot be reduced just by extracting output bits. If there is an entropy estimator based on the number of bits extracted, that estimator must be flawed. You're letting your intuition about usable randomness run roughshod over the formal definition of entropy. Taking bits out of the PRNG *does* reduce its entropy. By how much exactly? I'd say, _under the hypothesis that the one-way function can't be broken and other attacks fail_, exactly zero; in the real world, maybe a little more. But in /usr/src/linux/drivers/char/random.c I see that the extract_entropy() function, directly called by the exported kernel interface get_random_bytes(), states: if (r-entropy_count / 8 = nbytes) r-entropy_count -= nbytes*8; else r-entropy_count = 0; ...which appears to assume that the pool's entropy (the upper bound of which is POOLBITS, defined equal to 4096) drops by a figure equal to the number of bits that are extracted (nbytes*8). This would only make sense if those bits weren't passed through one-way hashing. Perhaps, a great deal of blockage problems when using /dev/random would go away with a more realistic estimate. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS passive sniffing
On Wed, 5 Jan 2005 08:49:36 +0800, Enzo Michelangeli said: That's basically what /dev/urandom does, no? (Except that it has the undesirable side-effect of depleting the entropy estimate maintained inside the kernel.) This entropy depletion issue keeps coming up every now and then, but I still don't understand how it is supposed to happen. If the PRNG uses a It is a practical issue: Using /dev/urandom to avoid waiting for a blocked /dev/random will let other processes wait infinitely on a blocked /dev/random. The Linux implementation of /dev/urandom is identical to /dev/random but instead of blocking, (as /dev/random does on a low entropy estimation) it continues to give output by falling back to a PRNG mode of operation. For services with a high demand of random it is probably better to employ its own PRNG and reseed it from /dev/random from time to time. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
I wrote: Taking bits out of the PRNG *does* reduce its entropy. Enzo Michelangeli wrote: By how much exactly? By one bit per bit. I'd say, _under the hypothesis that the one-way function can't be broken and other attacks fail_, exactly zero; in the real world, maybe a little more. If you said that, you'd be wrong. This is getting repetitious. As I said before, this is an abuse of the terminology. If you want to quantify the goodness of your PRNG, go right ahead, but please don't apply the word entropy to it. The word is already taken. It means something very specific. But in /usr/src/linux/drivers/char/random.c I see that the extract_entropy() function, directly called by the exported kernel interface get_random_bytes(), states: if (r-entropy_count / 8 = nbytes) r-entropy_count -= nbytes*8; else r-entropy_count = 0; ...which appears to assume that the pool's entropy (the upper bound of which is POOLBITS, defined equal to 4096) drops by a figure equal to the number of bits that are extracted (nbytes*8). This would only make sense if those bits weren't passed through one-way hashing. The linux /dev/random driver has lots of problems, but that's not one of them. That makes perfect sense. Anything else would not make sense. That's what entropy is. If you're not interested in entropy, then go measure whatever you are interested in, but don't call it entropy. Perhaps, a great deal of blockage problems when using /dev/random would go away with a more realistic estimate. 100% of the blocking problems go away if you use /dev/urandom to the exclusion of /dev/random. For the Nth time: a) Most of modern cryptography is based on notions of computational intractability. I'm not saying that's good or bad; it is what it is. b) My point is that there is an entirely different set of notions, including the notion of entropy and the related of unicity distance, which have got *nothing* to do with computational intractability. You can study (a) if you like, or (b) if you like, or both. Maybe (a) is best suited to your application, or maybe (b). But whatever you do, please don't mistake one for the other. Lots of things have large amounts of usable randomness, with little or no entropy. Please don't mistake one for the other. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AOL Help : About AOL® PassCode
Joerg Schneider wrote: So, PassCode and similar forms of authentication help against the current crop of phishing attacks, but that is likely to change if PassCode gets used more widely and/or protects something of interest to phishers. Actually I have been waiting for phishing with MITM to appear for some time (I haven't any yet ... By this you mean a dynamic, immediate MITM where the attacker proxies through to the website in real time? Just as a point of terms clarification, I would say that if the attacker collects all the information by using a copy of the site, and then logs in later at leisure to the real site, that's an MITM. (If he were to use that information elsewhere, so for example creating a new credit arrangement at another bank, then that technically wouldn't be an MITM.) Perhaps we need a name for this: real time MITM versus delayed time MITM? Batch time MITM? Assuming that MITM phishing will begin to show up and agreeing that PassCode over SSL is not the solution - what can be done to counter those attacks? The user+client has to authenticate the server. Everything that I've seen over the last two years seems to fall into that one bucket. Mutual authentication + establishment of a secure channel should do the trick. SSL with client authentication comes to my mind... Maybe. But that only addresses the MITM, not the theft of user information. -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Banks Test ID Device for Online Security
oh, and this is old discussion of a unit that has been in use in europe ... it basically is very inexpensive calculator with 7816 contacts that you can slip a smartcard into. it is used in a challenge/response scenario, a numeric keypad is used to enter the challenge, which is passed to the smartcard, which does something and the response is displayed. the person enters the displayed response. http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking works with anything that can present a challenge and has a numeric keypad for the response (even works over telephone with VRU). note that in any online scenario ... the server-side can do security proportional to risk by making a decision to ask or not ask for additional inputs. possible scenario is bill pay in home banking, use authentication for initial access and then if total transactions exceed some value ... ask for additional authentication input (trading off convenience and risk, in online scenario it doesn't need to be all just one way or another way, there is some amount of latitude for adaptive implementation). Note that the additional authentication input can also be used for interpreting the (human specific) input as evidence of approval for the transaction(s) as opposed to simply authentication. other pieces of the previous mentioned thread on security proportional to risk: http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#62 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#64 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#70 Net banking, is it safe??? http://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#10 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe??? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AOL Help : About AOL® PassCode
Florian Weimer wrote: I think you can forward the PassCode to AOL once the victim has entered it on a phishing site. Tokens à la SecurID can only help if Indeed. the phishing schemes *require* delayed exploitation of obtained credentials, and I don't think we should make this assumption. Online MITM attacks are not prevented. So, PassCode and similar forms of authentication help against the current crop of phishing attacks, but that is likely to change if PassCode gets used more widely and/or protects something of interest to phishers. Actually I have been waiting for phishing with MITM to appear for some time (I haven't any yet - if somebody has, I'd be interested to hear about), because it has some advantages for the attacker: * he doesn't have to bother to (partially) copy the target web site * easy to implement - plug an off-the-shelf mod_perl module for reverse proxy into your apache and add 10 minutes for configuration. You'll find the passwords in the log file. Add some simple filters to attack PassCode. * more stealthy, because users see exactly, what they are used to, e.g. for online banking they see account balance etc. To attack money transfers protected by PassCode, the attacker could substitute account and amount and manipulate the server response to show what was entered by user. Assuming that MITM phishing will begin to show up and agreeing that PassCode over SSL is not the solution - what can be done to counter those attacks? Mutual authentication + establishment of a secure channel should do the trick. SSL with client authentication comes to my mind... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
