TLS break
I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
* John Levine: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. There are some countries which use per-transactions one-time passwords. These methods has been broken as well. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. There are already some commercial implementations (e.g. those following ZKA's Secoder standard). IBM apparently has something in the works called ZTIC. There used to be the FINREAD standard. Attacks which would break these authentication schemes have already been observed in the wild. There are various means to trick people into providing authorization for fraudulent transactions. Tell them that they have the opportunity to buy an expensive car at a fraction of the price, or offer them a very attractive financial investment, for instance. $50 per device doesn't seem to be much, but you actually need a huge amount of fraud that's actually prevented until it's cost-effective to roll this out. I don't think banks which offer real electronic banking (that is, something pretty much like Paypal, but with consumer rights) can legally tell high-risk from low-risk customers, so you're basically stuck with general rollout. While $50 per device may seem a bit on the high side, I think it's not unrealistic if you consider costs associated with personalization, branding, etc. There's also the issue that a large amount of online banking happens from work during the lunch hour. USB dongles with software installation requirements are problematic for those users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto
On Wednesday,2009-11-04, at 7:04 , Darren J Moffat wrote: The SHA-256 is unkeyed so there would be nothing to stop an attacker that can write to the disks but doesn't know the key from modifying the on disk ciphertext and all the SHA-256 hashes up to the top of the Merkle tree to the uberblock. That would create a valid ZFS pool but the data would have been tampered with. I don't see that as an acceptable risk. I see. It is interesting that you and I have different intuitions about this. My intuition is that it is easier to make sure that the Merkle Tree root hash wasn't unauthorizedly changed than to make sure that an unauthorized person hasn't learned a secret. Is your intuition the opposite? I suppose in different situations either one could be true. Now I better appreciate why you want to use both a secure hash and a MAC. Now I understand the appeal of Nico Williams's proposal to MAC just the root of the tree and not every node of the tree. That would save space in all the non-root nodes but would retain the property that you have to both know the secret *and* be able to write to the root hash in order to change the filesystem. So if I don't truncate the SHA-256 how big does my MAC need to be given every ZFS block has its own IV ? I don't know the answer to this question. I have a hard time understanding if the minimum safe size of the MAC is zero (i.e. you don't need it anyway) or a 128 bits (i.e. you rely on the MAC and you want 128-bit crypto strength) or something in between. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 08.11.2009, at 01:07, John Levine wrote: I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Actually this type of problem is pretty common in Europe, most banks have to deal with malware that threatens their customers. One of the most advanced keyloggers out there is currently URLZone, which can also perform MitM attacks and transparently re-routes money transfers, defeating iTan (index transaction number) systems (see http://www.finjan.com/MCRCblog.aspx?EntryId=2345 ). There are several approaches to stop (or at least make it more difficult) this attack vector. A prototype of a system that implements the techniques described in your blog posting was presented by IBM Zurich about a year ago, see http://www-03.ibm.com/press/us/en/pressrelease/25828.wss for details. Other manufacturers implemented similar approaches, where some kind of trusted device is attached to the machine and also the banking card of the customer is used to verify transactions. Regards, Thorsten - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Effects of OpenID or similar standards
On Nov 6, 2009, at 4:19 PM, Erwan Legrand wrote: On Tue, Nov 3, 2009 at 9:41 PM, David-Sarah Hopwood david-sa...@jacaranda.org wrote: Jerry is absolutely correct that the practical result will be that most users of OpenID will become more vulnerable to compromise of a single password. Do you really believe most people use different passwords for different sites? Let's face it: most people use the same password for every single Web site they connect to. Starting from here, I can't see OpenID becoming much of a problem. While I'm sure this is widely believed, I wonder if it's really true. Is anyone aware of research on the subject? Even if it's true to a large degree, the details may matter. People may routinely use the same password for all their low value accounts, but come up with something better for their bank or other high value accounts. Paradoxically, the *lack* of a standard for password quality may help here. High-value sites often place some requirement on the nature of passwords, but the requirements vary: Letters and digits only; letters plus digits plus at least one special character - with the set of allowed special characters varying in pretty arbitrary ways; etc. It's tough to come up with a single password that will be broadly accepted at such sites, and anything someone does come up with will be so inconvenient that it's unlikely to be something they'll want to use at low-value, any- password-accepted, sites. A widely-used single sign on system is certainly great from a usability point of view, and does actually have some positive effects on security: You no longer need to hand your actual password to sites programmed by someone whose background in security is minimal. The downside is that you now have a single super-high-value password, the compromise of which would be very painful. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 8, 2009, at 2:07 AM, John Levine wrote: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. Wow. *That's* scary. When I said I'd been thinking about it for a while, he asked if I could write it up so we could discuss it further. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Technical content is fine, with one comment: You don't need a big keyboard to allow for a secure user login: Even a single one will do. You'd have a list of, say, 5 key words that you memorize. When the device turns on, it flashes a set of 10 words across the screen, one at a time for 1 second a piece (times/numbers subject to usability testing). Exactly one is from your list of 5; you need to press the button while your word is on the screen. Repeat this process 3 times and the chance of guessing the right words is 1 in a thousand. (Yes, someone can watch you using the device, but if it continues to the end of the set of 10 even after you press the button, it's a bit of a challenge to know which one you picked - and of course they could watch you type your password.) It does need another pass for typos and such - e.g., to defeat attacks that steal credentials and reuse *it* to set up another session later. I think $50 is a very high estimate. (Lynn Wheeler has described a design for a more powerful version of such a device that, as I recall, came in well under this figure a couple of years back.) Note that if the bank supplies the device - so that it necessarily knows any secret contained in it, and it's designed to be resistant to attempts to determine the secrets in it - then you don't need to use public key crypto; symmetric algorithms are just fine. These require very little compute power and memory. Once you assume that the secure endpoints are the device and the bank, the connection between the device and the PC is something you don't need to worry about. For somewhat higher cost than USB, you can use Bluetooth. Then the device can be anything. Look at the iPod shuffle and imagine how Apple might build such a thing. It could easily become a fashion accessory - a bank could get a lot of marketing mileage out of providing a fob with some famous designer's name on it. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: hedging our bets -- in case SHA-256 turns out to be insecure
On Nov 8, 2009, at 6:30 AM, Zooko Wilcox-O'Hearn wrote: I propose the following combined hash function C, built out of two hash functions H1 and H2: C(x) = H1(H1(x) || H2(x)) I'd worry about using this construction if H1's input block and output size were the same, since one might be able to leverage some kind of extension attack. That's not a problem for SHA256 or SHA512, but it's something to keep in mind if this is supposed to be a general construction, given that all likely hash functions will be constructed by some kind of iteration over fixed-size blocks. Rather than simply concatenating H1(x) and H2(x), you might do better to interlace them. Even alternating bytes - cheap enough that you'd never notice - should break up any structure that designs of practical hash functions might exhibit. (As a matter of theory, a vulnerability of alternate bytes is as likely as a vulnerability of leading bytes; but given the way we actually build hash functions, as a practical matter the latter seems much more likely.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS man in the middle
On Sat, 7 Nov 2009, Sandy Harris wrote: I'm in China and use SSL/TLS for quite a few things. Proxy connections, Gmail set to always use https and so on. This is the main defense for me and many others against the Great Firewall. Should I be worrying about man-in-the-middle attacks from the Great Firewall servers? The attack does not directly allow to see any plaintext, it only prepends your data with attackers plaintext. IMO if the Great Firewall administrator wanted to intercept TLS traffic they would do the usual TLS MitM attack with replacement of certificates (as done by some corporate firewalls). Using the renegotiation attack for purposes allowed by law seems to be too round about. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Effects of OpenID or similar standards
On Mon, Nov 9, 2009 at 3:17 AM, Jerry Leichter leich...@lrw.com wrote: On Nov 6, 2009, at 4:19 PM, Erwan Legrand wrote: Let's face it: most people use the same password for every single Web site they connect to. Starting from here, I can't see OpenID becoming much of a problem. While I'm sure this is widely believed, I wonder if it's really true. Is anyone aware of research on the subject? Not exactly, although I sure there was some research done on the number of passwords people had to remember nowadays and how many they were able to remember. Even if it's true to a large degree, the details may matter. People may routinely use the same password for all their low value accounts, but come up with something better for their bank or other high value accounts. For what it's worth (i.e. not much), in my own experience people who actually do this qualify as nerds. Paradoxically, the *lack* of a standard for password quality may help here. High-value sites often place some requirement on the nature of passwords, but the requirements vary: Letters and digits only; letters plus digits plus at least one special character - with the set of allowed special characters varying in pretty arbitrary ways; etc. It's tough to come up with a single password that will be broadly accepted at such sites, and anything someone does come up with will be so inconvenient that it's unlikely to be something they'll want to use at low-value, any-password-accepted, sites. Select any five letters long dictionary word of your choice, append 0 or 1 and you have a password one can reuse for almost all her accounts. I've seen real people do just that. A widely-used single sign on system is certainly great from a usability point of view, and does actually have some positive effects on security: You no longer need to hand your actual password to sites programmed by someone whose background in security is minimal. The downside is that you now have a single super-high-value password, the compromise of which would be very painful. Agreed. This word, usability, is the key here. I used to be very sceptical (to say the least) with regard to SSO systems. Then about everyone around gained access to the Internet and the World Wide Web. Then about every new Web site out there started requiring users to create accounts. The likes of OpenID have their use in today's world. Looking to this problem from another perspective, I'm yet to see any sensitive Web site (such as a banking site) relying on OpenID for authentication. But I must admit I haven't looked for one. Yet perhaps someone on this list knows better? -- Erwan Legrand Simplicity is prerequisite for reliability. -- E. W. Dijkstra - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Sun, Nov 8, 2009 at 7:07 AM, John Levine jo...@iecc.com wrote: So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Haven't read this thoroughly yet, though I think I disagree with the idea that the display should be minimal - imagine checking out of amazon on a 2-line display. Tedious. Anyway, I should mention my own paper on this subject (with Abe Singer) from NSPW 2008, Take The Red Pill _and_ The Blue Pill: http://www.links.org/files/nspw36.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
