US Banks: Training the next generation of phishing victims
Banks like Bank of America have taken some flak in the past for their awful online banking security practices. I was poking around their home page today because I wanted some screenshots to use as examples of how not to do it and I noticed the following incredible message, which appears when you click on the tiny padlock icon next to the login dialog: Browser security indicators You may notice when you are on our home page that some familiar indicators do not appear in your browser to confirm the entire page is secure. Those indicators include the small lock icon in the bottom right corner of the browser frame and the s in the Web address bar (for example, https). To provide the fastest access to our home page for all of our millions of customers and other visitors, we have made signing in to Online Banking secure without making the entire page secure. Again, please be assured that your ID and passcode are secure and that only Bank of America has access to them. Yep, no need to worry about those silly browser security indicators, just hand over your banking logon details to anything capable of displaying a Bank of America logo on a web page. (Another thing I noticed is that if you indicate that your logon state is WA or ID, you get sent to an HTTPS page which asks for your SSN alongside your name and password. Anyone know what legal requirement is behind that?) Amex is another example of this type of user training: Security is important to everyone! Please be assured that, although the home page itself does not have an https URL, the login component of this page is secure. When you enter your User ID and password, your information is transmitted via a secure environment, and once the login is complete, you will be redirected to our secure area. Wachovia has: Browser security indicators You may notice when you are on our home page that some familiar indicators do not appear in your browser to confirm the entire page is secure. Those indicators include the small lock icon in the bottom right corner of the browser frame and the s in the Web address bar (for example, https). To provide the fastest access to our home page, we have made signing in to Online Services secure without making the entire page secure. Again, please be assured that your ID and password are secure. (hmm, their admins must have gone to the same security night school as the BoA ones :-). Can anyone who knows Javascript better than I do figure out what the mess of script on those pages is doing? It looks like it's taking the username and password and posting it to an HTTPS URL, but it's rather spaghetti-ish code so it's a bit hard to follow what's going where. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
EDP (entropy distribution protocol), userland PRNG design
I am thinking of making a userland entropy distribution system, so that expensive HWRNGs may be shared securely amongst several machines. Here's the algorithm from generation to use: 1) Entropy harvested from HWRNG. 2) Entropy mixed with PRNG output to disguise any biases present in source. The Mersenne Twister suggests itself due to its extremely long period. (Is XOR sufficent and desirable?) 3) Entropy used as truly random input in an extractor to map somewhat random input (interrupt timing, memory contents, disk head settling times) into strongly random output. 4) Entropy passed through OWF to occlude state of previous systems in this chain. 5?) Entropy ciphered with a randomly-generated key (taken from the previous step), rotated periodically. 6) Entropy transmitted over the network. 7) Recipient ciphers the entropy with a randomly-generated key, rotated periodically. The randomly-generated key is taken from the output of step 8 so that data on the wire is never used directly to cipher future data sent over the wire (requiring an attacker to be able to accurately model step 8). 8) Recipient repeats steps 2-4 locally. 9) Entropy is used in an application needing it. Here's my claims: 1) There is no key distribution to worry about. 2) Eavesdropping only gets you known-ciphertext. You still have no idea about the plaintext, which is random, so you have no general way to recognize a successful brute-force attempt on the randomly-generated key used by the recipient. 3) You'd have to figure out how some part of the transmitted data was used by the recipient, and work forward with each trial key to see if the results match in order to recognize a successful guess at the key used in step 7. Would re-ordering data randomly on the recipient be useful to thwart this, or is it unnecessary? 4) The most effective way to compromise such a distribution system that I can think of would involve cracking the recipient system, and if the enemy can do that, no crypto can help you. I deliberately used the term cipher instead of en/decrypt because I am not sure it matters which direction we go, as long as it doesn't introduce any detectable statistical biases in the entropy (weakening it). What properties should I look for, and what level of assurances? Can you see any weaknesses or unnecessary steps in this model? I'm not sure 5 is necessary (it was just suggested by symmetry). Regarding the userland PRNG daemon, I was thinking of replacing the /dev/urandom functionality with a userland daemon, because: (a) cryptographic operations can be slow, and putting them in the kernel, which cannot block, is not desirable (b) development is easier, this will encourage people to tinker with it more (c) having the kernel perform HTTP requests to get random numbers from web sites is inappropriate What I want to do is: 1) Mix various sources of untrusted entropy in such a way as to make a strong claim as to the mixture. For example, these web sites offer free random numbers: http://www.random.org/ http://www.randomnumbers.info/ http://www.fourmilab.ch/hotbits/ Why shouldn't I download some numbers from these sites periodically, and combine them with the pool? I don't have to update the entropy count (indeed, this is a PRNG and so tracking actual entropy is somewhat irrelevant). The way I see it, if I XOR numbers from these sites with my PRNG output, even if an attacker eavesdrops on this traffic, I'm no worse off than if I hadn't used them at all. Unpredictability XORed with predictability is still unpredictable. Similarly, I also would like to use ID Quantique's HWRNG based on optics, but their modules are sealed and opaque. What I want to do is explore what kind of assurances I can make about the output, based on assumptions about the attacker's ability to control, predict, or observe one of the sources. 2) Occlude common biases in the HWRNG, which is the main input to the daemon. 3) Combine PRNG components in novel ways. 4) Create a plug-in framework for PRNG components. 5) Do it in a language not as prone to security-relevant errors as C and containing support for large numbers and bitstrings as first-class objects. I'm leaning towards python, heard good things about ruby, and open to suggestions that something very different like ocaml might be better. Stumbling blocks that I can see: 1) Lack of standardization in the naming or semantics of kernel facilities, such as the names of devices in /dev. 2) Lack of support for sockets in the target language. 3) The use of ioctls for interfacing to sources of entropy in the kernel. 4) The use of tty devices to interface to HWRNGs 5) Multiple clients petitioning the daemon for random bits at once. However, this is also a good thing; two consecutive values used by a client may not be consecutive outputs from the PRNG subsystem. Comments? -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier
Re: US Banks: Training the next generation of phishing victims
On Wed, Oct 12, 2005 at 09:36:58PM +1300, Peter Gutmann wrote: | | Can anyone who knows Javascript better than I do figure out what the mess of | script on those pages is doing? It looks like it's taking the username and | password and posting it to an HTTPS URL, but it's rather spaghetti-ish code so | it's a bit hard to follow what's going where. The phishers sure can, but they don't share. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EDP (entropy distribution protocol), userland PRNG design
On Wed, Oct 12, 2005 at 04:49:43AM -0500, Travis H. wrote: I am thinking of making a userland entropy distribution system, so that expensive HWRNGs may be shared securely amongst several machines. [...] Comments? -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson I can't say I a fan of the idea of having multiple ways of mixing entropy into the system. In particular, the idea of producing output by XORing your PRNGs output with the output of a semi-public RNG seems like a bad idea to me, because an attacker can easily control those values by taking over the web server or modifying packets in the network, and if they can somehow predict your PRNG outputs then they will be able to actually control the final output. The difference between knowing and controlling the PRNG output is a big deal when you're using it for something like DSA. I prefer a multi-stage design, as described by various people smarter than I am: source(s) -- mixer -- pool -- extractor -- X9.31 Take the sources, mix it into an entropy pool and then use an extraction function to derive values from the pool. Then use the values of that to seed a X9.31 PRNG and produce the final output with that (with the DT values also being generated by the extractor function). That helps make sure that even if you make a mistake with the extractor and/or mixer function you still have some level of protection. For example, even if an attacker can correctly guess every 16th bit of your extractor function, it will still be very difficult for them to guess the final PRNG outputs. I've found that it is much easier to think about the two functions as distinct, so you can reason about what specific properties you want or need the mixer and extractor to have, and it also makes it simpler to replace one or the other to make different security/speed tradeoffs. I believe most common hardware RNGs produce data at fairly high rates, often over 100 kbytes per second. If you have one of those you'll be able to get much more entropy from that than you will out of regular system sources, especially as the entropy of those samples usually decreases pretty strongly after the first sample or two, while the HWRNG keeps producing entropy at the same rate. Instead of treating the two entropy sources as somehow different in your mixing strategy, just use the HWRNG for most of the inputs, but every tenth sample (or whatever), instead use the hash of all the random-looking system data you can get ahold of. Only doing it occasionally means there is a reasonable chance that sufficient changes have happend to the system since the sample worthwhile in terms of entropy gained, and doing a large block of it all at once prevents iterative guessing attacks if an attacker can control your HWRNG outputs but not your system statistics. Encrypting the output using keys generated by the PRNG is a good idea, but you presented it in a somewhat confusing way, in that it sounded almost like you were doing message transfer. Then I realized you're not actually doing that at all, just a postprocessing (or preprocessing, in the case of the recipient) operation using a randomly keyed block cipher (which the X9.31 RNG would also provide nicely). At not point do the two sides actually exchange messages, so in this situation, your mention of key distribution is somewhat misleading. If you want to try to keep the entropy values sent from the box with the HWRNG to the client a secret from people on the network, just open up a TLS session. TLS is cheap if you use session resumption, and with self-signed certificates or anonymous DH there is no key distribution. It makes bootstrapping a little more difficult, but presumably the client can get at least some entropy via the traditional means currently available on common platforms. You could also just solve the problem you mention directly, and try to find a cheaper HWRNG design. I know people who have built them for a few dollars worth of stuff at Radio Shack, and apparently VIA, Intel, and AMD have all found them cheap enough at various times to ship them included in components they've built at little or no extra cost. You can buy a PCI board with a low-end Hifn crypto chip on it for less than $80 online. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: US Banks: Training the next generation of phishing victims
Peter Gutmann wrote: Can anyone who knows Javascript better than I do figure out what the mess of script on those pages is doing? It looks like it's taking the username and password and posting it to an HTTPS URL, but it's rather spaghetti-ish code so it's a bit hard to follow what's going where. Why have the log on your homepage at all? Why not just a link to the https login??? If the goal is to not have SSL overhead on the homepage, don't. Or is there some extra overhead for login processing that I don't know about? Is there some user dissatisfaction with an extra click to login? I suppose if you really wanted non-SSL logins, you could use a one-time passcodes system with variable length passcodes to prevent race attacks. -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
