Re: Maybe It's Snake Oil All the Way Down
Erik is right: there must be very strong motivation to consider using a cryptographic mechanism/protocol which is not `standard` (de-facto standards are Ok). When this motivation is supposedly improved security, the new (supposedly more secure) primitive should preferably be composed with a supposedly-weaker but standard mechanism, in a `cryptanalysis-tolerant` manner, i.e. an attack should apply to _both_ mechanisms. But of course other motivations (e.g. performance) may rule out this approach. The basic security argument underlying computational cryptography is always the fact that it withstood cryptanalysis. Even when we provide `provable security`, what the proofs really show is only that the mechanism/protocol is as secure as some other assumption. The only exception is unconditional secure systems such as one-time pad, but these are usually not practical (e.g. due to key length requirements); in particular public key systems are always `only` computationally secure. This is not really a problem and certainly not a motivation to design new systems, without a proof of security... Best, Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
At 18:31 07/07/2003 -0400, Tim Dierks wrote: ... So, it all boils down to a system that's not dissimilar to a traditional CA-based public key system. In order for you to participate, you go to the trusted third party, they verify that you own the e-mail address you're claiming to possess (with whatever level of verification they insist upon), and if you do, they generate your secret key for you and send it to you. You can now decrypt messages which other people encrypt with that public key. I don't think it's an interesting solution. I don't see any interesting application that's possible with this system which you couldn't do with existing public-key cryptography: for example, I could write a protocol software where you could request a public key ... Tim: wonderful concise summary and I couldn't agree more. Thanks for taking the time to explain so nicely why this kind of systems, while cute, are not really helping applied cryptography (IMHO). Best regards... Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Are there...one-way encryption algorithms
Enzo asked, Are there one-way encryption algorithms guaranteed to be injective (i.e., deterministically collision-free)? Or are there theoretical reasons against their existence? I'm looking for algorithms where every piece of code and data is public, thus excluding conventional enciphering with a secret key. Sounds like you look for One Way Permutations... which of course exist (if one-way functions do). But before we get into details, it'll be useful if you specify your needs more precisely since imprecision is the mother of weaknesses and break-ins. BTW I've updated my foils on encryption and hashing which cover much of this topic (see in site if interested). Best, Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Super-Encryption
Matt, in your note below you explained finally what you really want: a secure combination of encryption and signature. I explain below why your current scheme is insecure. There are simple secure designs. With Yitchak Gertner, a student, we recently proved security of one such practical design, which is essentially Sign_sender ( Encrypt_RSA_receiver (message), PublicKey_receiver). I've just uploaded the draft journal version to http://eprint.iacr.org/ so you should be able to see it in a day or so (comments very welcome as I want to finish and submit it to journal soon). Your scheme is using the Sign-then-Encrypt order, which may not be secure for some (possibly weird) encryption schemes, although may be secure standard schemes such as RSA (but I don't think this was proven yet). But as I mentioned, your specific scheme is definitely insecure, details below. Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name At 16:25 15/12/2003, Matt wrote: Quoting Ben Laurie [EMAIL PROTECTED]: I don't see any value added by cipher1 - what's the point? The message is encrypted, i.e, cipher1, then cipher1 is encrypted yeilding cipher2. Since symmetric_key1 of cipher1 is RSA_Encrypt(sender's private key), access to sender's public key can decrypt cipher1(must be *this* sender). So (as I said before...) here you are trying to authenticate the sender - using RSA to sign, not to encrypt. I again suggest you use the right terminology i.e. call is a signature (since this is what you do!). Notice also that for secure usage, there may be some small differences in the preprocessing for encryption vs. for signature with RSA. And I believe you didn't understand (and answer) Ben's point. I'll try to clarify. Here's the sequence you suggested: (1) Encrypt message with symmetric key algorithm, i.e., cipher1 That's the part that appears unnecessary. (2) RSA_Encrypt (SHA1(message) + symmetric key) with sender's RSA private key This is where you actually mean RSA_Sign. And why sign `symmetric key` ? Since the attacker will know this key, why not simply sign just `message` (or SHA1(message) if you want... normally we consider hashing as part of the signature process, i.e. I'll prefer to write Sign_RSA_SHA1(message)). (3) Encrypt cipher1 with symmetric key algorithm, i.e., cipher2 So here one would expect you to simply encrypt the message, i.e. cipher2=AES_symmkey2(message); Ben asks (and I agree), what gain do you have by encrypting cipher2? As I mentioned, one could hope for gain in confidentiality, e.g. when using different encryption schemes, but not when the first key (`symmetric key`) is revealed as in your protocol... (4) RSA_Encrypt (symmetric key2) with receiver's RSA public key So steps 3 and 4 are `classical` hybrid encryption of cipher1. Hybrid encryption is a standard technique so I prefer to write it as one step, i.e. Encrypt_RSA_AES_receiverPK(message), or in your case, Encrypt_RSA_AES_receiverPK(cipher1). (5) Send super-encrypted message Woops! what does the message consist of ? It is quite clear from the steps above and below (omitted), that it contains both cipher2=Encrypt_RSA_AES_receiverPK(cipher1) and also RSA_Sign_sender (SHA1(message) + symmetric key). Now this is a good example of why it is good NOT to confuse signature with encryption... since it is quite obvious that the attacker gets to see SHA1(message). This is not desirable. First of all, SHA1 (or any hash) is not required to preserve complete confidentiality (e.g. in the standard, the goal is only stated as being a one-way function). So attacker may be able to learn something about message from SHA1(message). As a practical example, suppose there is a very small set of possible messages, say `buy XXX for YYY' where XXX, YYY are from relatively small sets. Then clearly the attacker can simply compute SHA1(m') for all possible messages m' and identify the message sent. So this is a real possible exposure to confidentiality. Also, you wrote... Since symmetric_key2 of cipher2 is RSA_Encrypt(receiver's public key), only the receiver can decrypt cipher2. As was pointed out to me, the process of decrypting cipher2, yields an encrypted message, i.e., cipher1, that can forwarded on behalf of the original sender. This is not necessarily undesirable. However, SHA1(message) is to ensure that cipher1 has not be altered in transport. Therefore, the receiver knows three items. (1) The sender who originated the message. (2) The receiver is the intended receiver. This (item 2) is not correct. The message may have been sent to Eve (and encrypted using Eve's public key), but then Eve re-encrypted symmetric key 2 (or cipher1 itself) with the public key of another party say Bob, and sent the message to Bob; Bob has no way of knowing that the intended receiver (by the original sender) was Eve. (3) The message
Re: Super-Encryption
At 16:36 17/12/2003, Matt wrote: Ben, Amir, et.al. I see that cipher1 has no transparent value. Therefore, the XML-Encrypted message see ( http://www.w3.org/TR/xmlenc-core/ ) must transport (1) symmetric_IV (2) Sign_RSA_Receiver_PK(symmetric_Key) (3) cipher (4) Sign_RSA_Sender(SHA1(message)) This is still not very good. Comments: a. In (2) you obviously mean Encrypt_RSA not Sign_RSA b. In (4) you again send the hash of the plaintext in the clear. As I explained in my previous note, this is insecure, e.g. if plaintext is taken from a reasonably sized set (which is common), attacker can find the plaintext by hashing all the possible values. There are two fixes to this: sign the encrypted message and public key (which we proved secure for most PKCS including RSA) or encrypt the signed message (which may be vulnerable to Krawczyk/Bleichenbacher's attacks). c. Notice also (again as I wrote before...) that you don't achieve your stated goal of identifying the intended receiver. This is also solved if you sign the ciphertext and the receiver's public key, or simply sign the identity of the receiver. Anyway, I am repeating myself, so... Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
Ian proposes below two draft-definitions for non-repudiation - legal and technical. Lynn also sent us a bunch of definitions. Let's focus on the technical/crypto one for now - after all this is a crypto forum (I agree the legal one is also somewhat relevant to this forum). In my work on secure e-commerce, I use (technical, crypto) definitions of non-repudiation, and consider these as critical to many secure e-commerce problems/scenarios/requirements/protocols. Having spent considerable time and effort on appropriate definitions and analysis (proofs), I was/am a bit puzzled and alarmed to find that others in our community seem so vehemently against non-repudiation. Of course, like other technical terms, there can be many variant definitions; that is not really a problem (the community will gradually focus on few important and distinct variants). Also it's an unavoidable fact of life (imho) that other communities (e.g. legal) use the same term in somewhat different meaning. So my question is only to people like Ben and Carl who have expressed, if I understood correctly, objection to any form of technical, crypto definition of non-repudiation. I repeat: do you really object and if so why? What of applications/scenarios that seem to require non-repudiation, e.g. certified mail, payments, contract signing,...? Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name Enclosed: At 21:33 23/12/2003, Ian Grigg wrote: Amir Herzberg wrote: Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? I would second this call for some definition! FWIW, I understand there are two meanings: some form of legal inability to deny responsibility for an event, and cryptographically strong and repeatable evidence that a certain piece of data was in the presence of a private key at some point. Carl and Ben have rubbished non-repudiation without defining what they mean, making it rather difficult to respond. Now, presumably, they mean the first, in that it is a rather hard problem to take the cryptographic property of public keys and then bootstrap that into some form of property that reliably stands in court. But, whilst challenging, it is possible to achieve legal non-repudiability, depending on your careful use of assumptions. Whether that is a sensible thing or a nice depends on the circumstances ... (e.g., the game that banks play with pin codes). So, as a point of clarification, are we saying that non-repudiability is ONLY the first of the above meanings? And if so, what do we call the second? Or, what is the definition here? From where I sit, it is better to term these as legal non-repudiability or cryptographic non-repudiability so as to reduce confusion. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 18:02 29/12/2003, Ben Laurie wrote: Amir Herzberg wrote: ... specifications, I use `non-repudiation` terms for some of the requirements. For example, the intuitive phrasing of the Non-Repudiation of Origin (NRO) requirement is: if any party outputs an evidence evid s.t. valid(agreement, evid, sender, dest, message, time-interval, NRO), then either the sender is corrupted or sender originated message to the destination dest during the indicated time-interval. Notice of course that sender here is an entity in the protocol, not the human being `behind` it. Also notice this is only intuitive description, not the formal specifications. What you have here is evidence of origin, not non-repudiation. Ben, thanks, I'll change to this term (`evidence` instead of `non-repudiation`) since it appears from this thread that it may avoid confusion (at least for some people). Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Homepage (and lectures in applied cryptography, secure communication and commerce): http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why penny black etc. are not very useful (could crypto stop spam??)
At 17:38 30/12/2003, Perry wrote: In my opinion, the various hashcash-to-stop-spam style schemes are not very useful, because spammers now routinely use automation to break into vast numbers of home computers and use them to send their spam. They're not paying for CPU time or other resources, so they True. But, as Ben noted, the user of the machine could and should care about the resource. Now one may claim that many users don't pay attention to viruses stealing huge amounts of their CPU time. So I agree that the `waste CPU time to pay for sending mail` may have limited effect to stop spam. I also rather dislike the notion of wasting resources to send every e-mail. But where I quite disagree with you is when you say... snip... 1. We need public key authentication of all mail. Well, I'll point out that large integers are cheap and plentiful. Authenticated spam is pretty much as bad as non-Authenticated spam. If we use IMHO, your conclusion is wrong: cryptographic authentication could be a critical tool to stop spam; someone in our community should do this (write the software) already... How? E-mail (at least from new correspondents) must be signed by an `anti-spam mail certification authority (ASMCA)` - often the ISP of the sender. Recipient's mail client (or server) will reject mail (from new correspondents) not certified by a trustworthy ASMCA. If the mail was not rejected but later identified (by end user) as spam, the recipient client/ISP will not only know not to trust the sender's ASMCA, they will also have `proof` that this ASMCA approved (signed) this spam, so they can inform other ASMCA's and mail client/servers. Results: - ASMCA's have strong incentive not to approve spam. They'll use appropriate measures, mainly: filtering tools and punishing spammers (blocking accounts, charging fines, etc.) - End users whose machines were broken into will be notified by their ASMCA (usually ISP), when it detects the spamming by filtering tools or by complaints, and will (1) know there's a problem and take measures to get rid of the spamming trojan horse and (2) maybe be a bit more careful about the machine in the future. Desired side effects: - users will also enjoy e-mail authentication (and confidentiality could be added trivially) - which in particular will make it a bit more difficult for e-mail viruses to propagate. What's the bug in this simple solution? If anybody wants to implement I'm willing to assist in developing/validating the protocols. Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Homepage (and lectures in applied cryptography, secure communication and commerce): http://www.cs.biu.ac.il/~herzbea - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Looking for mirror (or: better) sites to host my crypto/security lectures
I keep the foils of my courses `intro to applied crypto` and `intro to secure communication and commerce` online at http://www.cs.biu.ac.il/~herzbea/book.html. Total of about 15 topics, each covered by pretty extensive set of foils (planned for between one and four 2-hour sessions for each topic). However, I've had a lot of complaints about downloading my lectures from this (university) server, from people outside the university (it seems to work fine for my students). And fixing the problem here is bound to be painful. Plus anyway our location is not ideal (in many ways :-). So, if anyone has a reliable ftp server where I could post the lectures (and update them via ftp), please let me know. The foils currently take about 25MB but I think I need at least 50MB and preferably 100MB so I can put additional stuff. I prefer a non-commercial site, which can be reasonably reliable and persistent. In the meanwhile, if you find you cannot download the files, I guess I'll have to send by e-mail... Unfortunately these are pretty large files. Needless to say, technical comments and corrections are also (or: especially) welcome. Best regards, Amir Herzberg Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
recommendations/evaluations of free / low-cost crypto libraries
I will appreciate experience-reports/evaluations/comparisons with free or low cost (and in particular zero `per seat` cost) crypto libraries, especially in C / C++ (or links to web-sites containing them). If I'll get substantial useful information (off-list) I'll try to compile it and send to the list. Important aspects include reliability, functionality, performance, documentation, cost (for development system - no `per seat` cost!), and licensing terms (in particular can it be used for commercial products, and any restrictions). Thanks a lot... -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Using crypto against Phishing, Spoofing and Spamming...
Following some of our discussions on this list, I tried to think more seriously on how crypto could be used for the basic current security threats of spoofing, phishing and spamming. Preliminary write-ups of the results are available in the following (or from my homepage): # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF # Controlling Spam by Secure Internet Content Selection, at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spam.pdf I believe many of you will find some interest in (criticizing?) the new ideas and proposals, and I'll be very grateful for any feedback; the works already benefited a lot from some discussions on this list, including some of you who asked me essentially to `write up your ideas`. I am also very interested in working with potential implementors; I am already working on implementations with students, but, additional and potentially more experienced developers may help us turn some of these ideas into reality. BTW, I'm already using the anti-spamming mechanism (trusted logo and credentials area) we developed for Mozilla, and it works great; I hope we'll feel soon confident enough with the code so we'll be able to put it in the public domain. Experienced Mozilla developers who will be willing to help test and evaluate the code are invited to contact me. -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://AmirHerzberg.com (information and lectures in cryptography security) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Florian Weimer wrote: * Amir Herzberg: # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF The trusted credentials area is an interesting concept. Thanks. However, experience suggests that given the current business models, we cannot build the required logotype registry. All registries which are used on the Internet (for IP address assignments, BGP prefixes, DNS names, and even X.509 certificates) are known to fail under stress. I'm not sure what you mean by `logotype registry`. Such a registry already exist (off-web), i.e. national trademark offices, e.g. www.uspto.gov. These bodies could issue logo certificates. Or, private companies, e.g. verisign, can issue logo certificates, based on the official trademark registers; that shouldn't be hard. As to a registry to hold these certificates - the site (e.g. bank) would probably keep it... and many other places (this is signed i.e. not risky to keep). Finally, of course, until such certificates are available, we simply use the manual binding of logos/icons/names to public keys, on the first time you enter a secure site using a browser with our enchancement. It works great... very convenient, and very clear (see screen shots in paper). -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Can crypto help against Phishing, Spoofing and Spamming...
Reminder: following lots of discussion on this list, I wrote proposals on how crypto can help solve phishing, spoofing and spamming problems. Apparently few had problems downloading the PDF files from our (BIU) site. so I've put both papers in ecrypt (which I believe is more reliable), and also, I've put HTML version in our site. So, I apologize for the inconvenience if you tried before and got nothing, but these links should work fine, and I am very interested in your feedback: # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://eprint.iacr.org/2004/155/ and http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/Spam.htm # Controlling Spam by Secure Internet Content Selection, at http://eprint.iacr.org/2004/154/ and http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/Spam.htm -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: EZ Pass and the fast lane ....
If they could read the license plates reliably, then they wouldn't need the EZ Pass at all. They can't. It takes human effort, which is in short supply. The toll road that began operating here in Israel seems able to read your license plate number, without even requiring cars to slow down (and they definitely _don't_ slow down...). So I think this observation about EZ Pass is probably true, but for some time ago; with current technology, reading license plates is possible (which, I guess, has some alarming privacy implications...). Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: Using crypto against Phishing, Spoofing and Spamming...
Ian Grigg wrote: This indeed is the crux of the weakness of the SSL/secure browsing/CA system. The concept called for all CAs are equal which is an assumption that is easily shown to be nonsense. Exactly. Browsers simply require sites to have a certificate from any CA. Browswers can't even specify a list of their prefered/acceptable CA... This made it easier for SSL to roll-out, but, like you say, made certificates into commodities and almost meaningless. skip The essence of any fixes in the browsers should be to address the (rather fruitful) diversity amongst CAs, and help the user to make choices amongst the brands of same. Agreed! Some CAs are more equal than others... and the sooner a browser recognises this, the better. Agreed! Except, I think that the user may also be involved in recognizing the more trustworthy CA, e.g. by including also a logo of the CA in the TCA - so I can see, `this site is IBM (since I see their logo) and this was validated by Verisign and/or the USPTO (since I see their `logo certified by` logo(s)). These bodies could issue logo certificates. Exactly! These certificates would only have value if there is extensive verification. We probably lack the technology to do that cheaply right now, and the necessary level of international cooperation. I'm not sure I agree here. I think that many logos (e.g. of international companies) are already well protected by the existing network of trade mark offices. As to smaller companies, they would be protected by the logo but also by including icons/seals of credentials in the Trusted Credentials Area. E.g., getting back to your example, a site such as Perry's, which contain professional crypto information, should be able to get a credential from organizations such as IACR or ACM or Financial Cryptography or... and I guess these places would not give a credential (certainly not to the same logo) for a resturant. So, the site logo becomes more meaningful when accompanied by the Logo Certifying Authority logo, and/or by appropriate credentials. I'm not sure I understand how logo certs would work, as there is still the possibility of same being issued by CA-Nigeria and having remarkable similarity to those issued by USPTO. Let's not pick on Nigeria, but I get your point; but why should you set your browser to trust logo certificates from an LCA you don't trust?? The site can obtain multiple logo certificates if it wants its logo to be internentionally trusted. Until the CA is surfaced and thrust at the face of the user, each browser's 100 or so root CAs will be a fundamental weakness. Including of course the absence of CA, which is something that is nicely hidden from the user. Agreed. We already planned to have the LCA's logo in the TCA but I'll modify the paper (and code) to make this more clear and visible. Thanks! BTW, notice that by default, and considering there is no CA certifying logos yet afaik, you simply have to validate the (regular) certificate on the first time you get a public key from the server... -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: Question on the state of the security industry
[EMAIL PROTECTED] wrote: McAfee Research has proposed solutions to some of their larger customers and has an anti-phishing white paper: http://www.networkassociates.com/us/_tier2/products/_media/mcafee/wp_an tiphishing.pdf the paper, at: http://www.networkassociates.com/us/_tier2/products/_media/mcafee/wp_antiphishing.pdf contains excellent review of the area and of the known, existing tools (anti-virus, spam-filter, ...) and good practices for users and corporations. Michael, I've noted that the authors acknowledged you, so could you forward them our proposal (at my homepage or directly at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm), I'll love to hear their feedback.. -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: Can crypto help against Phishing, Spoofing and Spamming...
John Levine wrote: Reminder: following lots of discussion on this list, I wrote proposals on how crypto can help solve phishing, spoofing and spamming problems. ... # Protecting (even) Naive Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://eprint.iacr.org/2004/155/ (or off http://AmirHerzberg.com) This is a pretty good paper. It outlines the problem and proposes that browsers add a trusted credential area that displays a site logo that has to be signed by a CA using SSL, in a way that is hard to spoof or forge. Thanks! But, our prototype (for Mozilla) allows you also to select the Logo (or icon) for the site manually, although having it already signed by a trusted authority could be nice. Also: the trusted area can also display other credentials of the site, and in particular - logo and/or name of the CA. I've been discussing a similar idea with a lot of people that has one important difference: the seal belongs to the CA and is distributed as part of the verification certificate. Per-site logos have the disadvantages that there are a lot of sites, not all with famous logos, and there are a lot of CAs, most of whose primary verification technique is to be sure your check didn't bounce. I completely agree that existing CA solution in browser is lousy; did you notice that the main requirement to become a CA is to be a CPA (certified public accountant) and pay 1400$ to WebTrust? (more in paper) That's why manual logo approval by the users is an important first step (works great - I don't know how I ever used e-banking without it). Second step may be for users to share these user-certified logos, and finally - for some trustworthy organizations to provide logo certificates. In most industries there is a regulator or trade association who already knows who the legitimate players are. That's who should be running the CA for that industry, with an industry wide logo that they could advertise, something like a golden dollar sign that tells you that a site is really a bank. I spoke briefly to a guy from the FDIC at last year's antiphishing meeting who said they'd been thinking of something like that. Agree! We call this a credential, see in paper or just this screen shot http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing_files/image006.gif -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
On SSL, SET, `real PKI` and real code against Phishing/Spoofing
brief comments/suggestions: 1. The whole discussion on how much eavesdropping is a threat is irrelevant. We all know it is a threat and the level is not important, as SSL/TLS provide a good, inexpensive solution. Drop this topic. 2. Stop beating the dead horse (SET). But yes, we should learn from mistakes... and Steve is right: SET main failure was lack of incentive to buyers and sellers. Such an incentive was our design assumption and I was assured by the CC `suits` they'll do it, but when they did, it was too little and much too late. And also they added so much baggage on this poor protocol that it became really so complex. But I am proud of few things in SET, especially... It wasn't even a real PKI ... No, exactly, it wasn't. Because what you refer to as `real PKI` (see original note...) - identities, revocation etc. - are not needed for this application (and many others). We need to use the tool that fits the job. 3. Which brings us back to SSL and Ian's objection... I think Ian _really_ objects to the fact that the major SSL/TLS deployments (browsers, servers) depend on `browser PKI`. And I agree: I think the `browser PKI` is a sad joke (on us), with the weakly-secure, not-really-trusted list of over-100 CAs. We can do much better - use SSL, but checking certificates better; display the logo of the site and/or of the CA, and allow users to decide on sites they trust (and their logos) manually... We have been discussing these things on this list for ages, and some even asked `is there a real use for crypto`. Then, with Ahmad, we implement and document a cute little extension to Mozilla that uses SSL and certificates, but probably not what some may call `real PKI`. And guess what? You go back to argue on SSL vs. SET and such. Guys: give us some feedback! Ok, it's a paper, not a note, but it is really pretty easy reading. And if this is too much, at least look at the screen shot: http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing_files/image006.gif And then speak up - is it the right approach? Should we change something before releasing (hoping in a week or two) or longer term? Can you do it for IE or other browser? (for the paper, see my homepage as below...) -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) Mirror site: http://www.mfn.org/~herzbea/ begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com , mirror: http://www.mfn.org/~herzbea/ version:2.1 end:vcard
Re: dual-use digital signature vulnerability
Barney Wolff wrote: Pardon a naive question, but shouldn't the signing algorithm allow the signer to add two nonces before and after the thing to be signed, and make the nonces part of the signature? That would eliminate the risk of ever signing something exactly chosen by an attacker, or at least so it would seem. Most (secure) signature schemes actually include the randomization as part of their process, so adding nonces to the text before signing is not necessary. OTOH, I don't see any problem in defining between the parties (in the `meta-contract` defining their use of public key signatures) that the signed documents are structured with a random field before and after the `actual contract`, as long as the fields are well defined. -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) Mirror site: http://www.mfn.org/~herzbea/ begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com , mirror: http://www.mfn.org/~herzbea/ version:2.1 end:vcard
Re: Websites, Passwords, and Consumers (Re: CRYPTO-GRAM, August 15,2004)
R. A. Hettinga wrote: At 11:26 PM -0500 8/14/04, Bruce Schneier wrote: Websites, Passwords, and Consumers Criminals follow the money. Today, more and more money is on the Internet. Millions of people manage their bank accounts, PayPal ... though the security problem has nothing to do with the bank, ... The banks have nothing to do with it? Banks are often acting irresponsibly and making it easier for phishers to lure their customers, by... 1. not protecting the login pages using SSL/TLS, e.g. www.chase.com (more examples here: http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing_files/image005.gif) 2. not using meaningful, consistent domain names (one of the following is spoofed: http://tdwaterhouse.ip02.com, http://citibank-verify.4t.com) 3. not giving correct advice to customers (too many examples...) 4. not using signed e-mail to send their messages... ... and more... -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) Mirror site: http://www.mfn.org/~herzbea/ begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com , mirror: http://www.mfn.org/~herzbea/ version:2.1 end:vcard
Can you help develop crypto anti-spoofing/phishing tool ?
We develop TrustBar, a simple extension to FireFox ( Mozilla), that displays the name and logo of SSL protected sites, as well as of the CA (so users can notice the use of untrusted CA). I think it is fair to say that this extension fixes some glitches in the deployment of SSL/TLS, i.e. in the most important practical cryptographic solution. TrustBar works pretty well for several alpha users. The solution benefited a lot from discussions on this list, including substantial input by Ian. You can download it from http://trustbar.mozdev.org (and it is completely script so what you download is also the source code). I am hoping some of you may be able to help improve, evaluate and deploy this solution. In particular, we need implementations for other browsers (e.g. IE...); we can also use help in continuing our development as several pretty cool ideas are not done yet, due to other commitments of us (Ahamd Gbara and me). For example, we designed a simple mechanism to allow sites to protect (cryptographically) also pages where SSL is too expensive, but it is waiting for implementation for a while... And of course we need evaluations, code reviews, testing... In fact, I wouldn't object if some serious open-code developer assumed responsibility... If people are interested, and want to discuss face to face, I'll be in RSA on 15-18/February... Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you help develop crypto anti-spoofing/phishing tool ?
Daniel Carosone responded to me: We develop TrustBar, a simple extension to FireFox ( Mozilla), that displays the name and logo of SSL protected sites, as well as of the CA (so users can notice the use of untrusted CA). Other merits of the idea aside, if the user knows the CA is untrusted, what's it doing in the browser's trust path? Unfortunately, users are not aware of what is a CA, and can't recognize trusted CAs. This fact is pretty obvious, but I've also validated it by appropriate user surveys (initial results already appear in the paper, see at my site http://AmirHerzberg.com; and I already have additional supporting results). However, by exposing the brand (identity, logo) of the CA, and using simple terms (`identified by`) rather than jargon (CA), we allow users to identify suspect certifications, and we allow CAs to establish their brand - which, imho, is a good thing. I find it almost a professional insult, that people go for non-crypto identification mechanisms to prevent spoofing and phishing. I mean, if we can't sell crypto for this purpose, this - imho - is a real failure. Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you help develop crypto anti-spoofing/phishing tool ?
Ed Gerck responded to me: We develop TrustBar, a simple extension to FireFox ( Mozilla), that displays the name and logo of SSL protected sites, as well as of the CA (so users can notice the use of untrusted CA). I think it is fair to say that this extension fixes some glitches in the deployment of SSL/TLS, i.e. in the most important practical cryptographic solution. Yes, because it makes the user notice what CAs the _browser_ has decided the user _automatically_ accepts [1]. But there is a caveat. Can you trust what trustbar shows you? This trust translates to: -- Trusting the TrustBar code (which is open source so can be validated by tech-savvy users / sys-admin) -- Trusting that this code was not modified (same as for any other aspect of your machine) -- Trusting the CA - well, not exactly; TrustBar allows users to specify for each CA whether the user is willing to display logos/names from this CA automatically, or wants to be asked for each new site. Only if the user selects `display logo/name automatically`, then he really trusts the CA in this regard, and still the brand (logo) of the CA appears (for accountability). I'll admit, though, that currently VeriSign is `trusted` in this respect by default (of course user can chnage this easily). And, of course, knowing what CA is being used is also possible without trustbar but requires a couple mouseclicks. Wouldn't it be better if Firefox/Mozilla simply put the name of the CA next to the lock icon? I don't think this is enough: a) not visible enough b) not clear enough (what this means) c) does not allow user to distinguish between different companies with cert from the same CA (i.e. you lose the identification of the site by name/logo and resort back to the SSL `identify by URL` which is too complex for naive users). Thanks (also for the URL)! Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Want to see a simple, working method to spoof sites, fooling Mozilla/FireFox/... , even with an SSL certificate and `lock`? http://www.shmoo.com/idn/ See also: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3866526512 Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions? Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Taral wrote: On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote: Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions? Why should I trust you? Filtering xn--* domains works for me, and doesn't require that I turn my browser over to unreviewed, possibly buggy code. Sorry if I was not clear: I don't propose you install TrustBar because YOU need it as a solution. Many people on this list are security/crypto experts, interested in finding good solutions (for all/many users, not just for themselves), and my message was for them. And yes, while TrustBar works fine for me and apparently quite a few others, the current code is only a research prototype (on the other hand, I had already the good fortune of seeing similar research code being adopte3d by many products... e.g. with our IP-Sec code). Best, Amir - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Steve, my point was not the trivial fact that TrustBar would not display the homograph; suppose it did... even then, the user is _asked_ about the certificate, since it was signed by an unusual CA that the user did not specify as `to be trusted always`; this should certainly be a good warning for most users (and of course, a good situation to check for tricks such as homographs...). And even if some user allowed this CA as `always trusted`, there is still a fair chance he'll notice that the brand of CA on his bank's site has suddenly changed... which may also raise the alarm. Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Taral wrote: On Wed, Feb 09, 2005 at 09:08:45PM +, Ian G wrote: The plugin is downloadable from a MozDev site, and presumably if enough attention warrants it, Amir can go to the extent of signing it with a cert in Mozilla's code signing regime. This, of course, is up to Mozilla, not to me... We are trying to get Mozilla (and other browsers) to adopt the idea. I guess, once they do, they'll do a review and then sign, as first step towards integrating it into the browser package (you can't expect to protect all/most users, including naive, with an extension - signed or not...). That only authenticates that Amir wrote the code, not that the code is safe. Absolutely! And I didn't write the code, btw, Ahmad did. I'm just writing designs, protocols, proofs, papers... (I like programming but rarely get to it, I'm afraid). Also, as Amir is a relatively well known name in the world of crypto I suppose you could consider his incentives to be more aligned with delivering good code than code that would do you damage. thanks! *This* is a reasonable argument, but I'd prefer a second-party review before I install anything. Of course; again: by posting on this list I am exactly encouraging people to review the code (it is all script so you can just download TrustBar and read it), write their own better code, etc... Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PK - OTP?
Matt Crawford wrote: My educated-layman's opinion is that the following is not feasible, but I'd be happy to be shown wrong ... Given a closed public-key device such as a typical smart card with its limited set of operations (chiefly sign), is it possible to implement a challenge/response function such that * Both the challenge and the response are short enough for an average user to be willing to type them when needed. * The challenge can be generated, and the response verified using the cardholder's public key and a reasonable amount of computation. What's wrong with sending the device encryption of a random number (using the public key of the device), and the device sending back the number as proof of possession of the corresponding secret key? Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: $90 for high assurance _versus_ $349 for low assurance
John, thanks for this fascinating report! Conclusion? `Not all CAs/certs are created equal`... therefore we should NOT automatically trust the contents of every certificate whose CA appears in the `root CA` list of the browser. Instead, browsers should allow users to select which CAs they trust sufficiently to identify sites, and to _know_ which CA is identifying the (protected) site they use. This is easy to do, and of course you can add this to your Mozilla/FireFox browser by installing our TrustBar (from http://TrustBar.mozdev.org). Best, Amir Herzberg John Levine wrote: Does anyone have a view on what low and high means in this context? Indeed, what does assurance mean? Just last week I was trying to figure out what the difference was between a StarterSSL certificate for $35 (lists at $49 but you might as well sign up for the no-commitment reseller price) and a QuickSSL cert for $169. If you look at the bits in the cert, they're nearly identical, both signed by Geotrust's root. As far as the verification they do, QuickSSL sends an e-mail to the domain's contact address (WHOIS or one of the standard domain addresses like webmaster), and if someone clicks through the URL, it's verified. StarterSSL even though it costs less has a previous telephone step where you give them a phone number, they call you, and you have to punch in a code they show you and then record your name. Score so far: QuickSSL 0.001, StarterSSL 0.0015. Both have various documents available with impressive certifications from well-paid accountants, none of which mean anything I can tell. Under some circumstances they might pay back some amount to someone defrauded by a spoofed cert, but if anyone's figured out how to take advantage of this, I'd be amazed. Comodo, who sell an inferior variety of cert with a chained signature (inferior because less software supports it, not because it's any less secure) is slightly more demanding, although I stumped then with abuse.net which isn't incorporated, isn't a DBA, and isn't anything else other than me. I invented some abuse.net stationery and faxed them a letter assuring that I was in fact me, which satisfied them. Back when I had a cert from Thawte, they wanted DUNS numbers which I didn't have, not being incorporated nor doing enough business to get a business credit rating, so they were satisfied with a fax of my county business license, a document which, if I didn't have one, costs $25 to get a real one, or maybe 15 minutes in Photoshop to make a fake one good enough to fool a fax machine. I gather that the fancier certs do more intrusive checking, but I never heard of any that did anything that might make any actual difference, like getting business documents and then checking with the purported issuer to see if they were real or, perish forbid, visiting the nominal location of the business to see if anything is there. So the short answer to what's the difference between a ten dollar cert and a $350 cert is: $340. Next question? Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I shook hands with Senators Dole and Inouye, said Tom, disarmingly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] . - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work (and how to get it used...)
I think this is a good summary of how it should work, except, that I don't think messages should be signed by default, only authenticated (MAC). Users should be clearly aware of making a non-repudable statement. Plus, it may be preferable to use something like matasignatures.org to ensure authenticated e-mail does not alarm recipient with non-compliant e-mail clients. A missing element is motivation for getting something like this deployed... I think spam could offer such motivation; and, I strongly believe that a cryptographic protocol to penalize spammers could be one of the most important tools against spam. I've presented such a simple crypto protocol (SICS) in SCN'04 [available off my site], and now work on open-source implementation (with student Jonathan Levi) of an improved version (SICSv2...), to be published soon. [I can send draft to experts willing to provide feedback...] Best, Amir Herzberg James A. Donald wrote: -- In my blog http://blog.jim.com/ I post how email encryption should work I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * The user should automagically get his certified key when he sets up the email account, without having to do anything extra. We should allow him the option of doing extra stuff, but the default should be do nothing, and the option to do something should be labelled with something intimidating like Advanced custom cryptographic key management so that 99% of users never touch it. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with advanced custom options, his from address must be the address that the client downloads mail from as it normally is. * The email client learns correspondent's public keys by receiving signed email. It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. * The signature is in the mail headers, not the body, and signs the body, the time sent, the sender's address, and the intended recipient's address. If the email is encrypted, the signature can only be checked by someone who possesses the decryption key. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages that are a reply to someone using similar software, and neither he nor those he corresponds with notice anything different or have to do anything extra other than that when he gets unsigned messages, or messages with an key different from the previously used key, a warning comes up an unobtrusive and easily ignored warning if he has never received a signed message from that source, a considerably stronger warning if he has previously received signed mail from that source. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx 4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] . - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Trojan horse attack involving many major Israeli companies, executives
Possibly the most visible Trojan attack was just exposed by the Israeli police. The Trojan was written (apparently) by an Israeli programmer, living in Europe in the last few years. It was planted in many Israeli companies, such as the major cellular companies. There were conflicting reports so far on the distribution method, and it may have used several, such as a program sent by e-mail or on CD to company. The scheme had three layers: the programmer; several `private investigation` companies (including the largest in Israel!); and the customers (including many hi-profile Israeli companies). The victims were also many leading Israeli companies. A lot of confidential documents were disclosed (via FTP to several servers, from which the customers downloaded the documents). This is a story worth a movie, really, since there is also a personal and media issue here... This whole thing was discovered not by any of the victim companies, but by a different victim: a well-known couple who wrote a `psychology-thriller`. The wife is the more well known; she is the host of an extremely popular (and controversial) talk-radio show, consulting listeners on different personal problems. This couple were apparently targeted by the Trojan for personal reasons; the programmer is their ex-son-in-law... See more info e.g. at http://www.haaretz.com/hasen/spages/581790.html -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trojan horse attack involving many major Israeli companies, executives
John, yes, I believe the Trojan ran on Windows. In fact, I just met my kids schoolmaster, and turns out she was also a victim of that person - already 3-4 years ago!!! Her daughter learned with his in the same school, and apparently he got mad at them and started abusing them in the most crazy ways - for instance, he intercepted family pictures sent to them, and _disfigured_the_pictures!! She went to the police but I guess was less lucky and they didn't find him, she changed computers, dial-up connection, etc. etc... As you say - movie stuff. Amir John Saylor wrote: hi ( 05.05.30 15:34 +0200 ) Amir Herzberg: See more info e.g. at http://www.haaretz.com/hasen/spages/581790.html an excellent tale [still unfolding]- no doubt coming to a bookstore or movie theatre near you real soon. of course, it was never mentioned in the article, but they *had* to be running windows. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
With bank web sites, experience has shown that only 0.3% of users are deterred by an invalid certificate, probably because very few users have any idea what a certificate authority is, what it does, or why they should care. (And if you have seen the experts debating what a certificate authority is and what it certifies, chances are that those few who think they know are wrong) Well, I have some usability tests that seem to prove your intuitive claim that most users don't know what's a CA. I don't know about arguments between experts on this. I think however that even naive users understand quite the TrustBar UI for SSL protected sites. We display something like name/logo of site identified by name/logo of CA. I'll appreciate your thoughts/feedback, try it at http://TrustBar.MozDev.org. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trojan horse attack involving many major Israeli companies, executives
J.A. Terranson wrote: So, how long before someone, possibly even me, points out that all Checkpoint software is built in Israel? Nicely put, but I think not quite fair. From friends in financial and other companies in the states and otherwise, I hear that Trojans are very common there as well. In fact, based on my biased judgement and limited exposure, my impression is that security practice is much better in Israeli companies - both providers and users of IT - than in comparable companies in most countries. For example, in my `hall of shame` (link below) you'll find many US and multinational companies which don't protect their login pages properly with SSL (PayPal, Chase, MS, ...). I've found very few Israeli companies, and of the few I've found, two actually acted quickly to fix the problem - which is rare! Most ignored my warning, and few sent me coupons :-) [seriously] Could it be that such problems are more often covered-up in other countries? Or maybe that the stronger awareness in Israel also implies more attackers? I think both conclusions are likely. I also think that this exposure will further increase awareness among Israeli IT managers and developers, and hence improve the security of their systems. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Hall of Shame of Unprotected Login Sites, and Phishing/Spoofing FAQ
Many important, sensitive login sites are not protected, making it easier to steal passwords from naive (and even experienced) users. See `Hall of Shame` listing such sites at http://www.cs.biu.ac.il/~herzbea/Shame.html Examples: Banks and FIs: PayPal, Chase, SmithBarney (CitiGroup), Bank of America, TD Waterhouse, Amex, FirstCommand Bank, MidFirst Bank Security services: MicroSoft Passport, EquiFax, InstantSSL All sites were warned before being added to the Hall of Shame (few actually fixed their sites and are therefore not on the page, e.g. eBay). A related resource - a FAQ on phishing and spoofing, at http://www.cs.biu.ac.il/~herzbea/shame/FAQ.htm -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: PapersaboutAlgorithm hiding ?)
Ken, you are correct (see below). And in fact, if the page came from the right source (as validated by SSL and a secure browser extension such as TrustBar), I don't think there is any need to validate the source (which is impractical even for the geekest geek). After all, if a site is so clueless as to send you corrupted scripts, it may as well publish your password directly... Best, Amir Herzberg Ken Ballou wrote: Unless I misunderstand, the problem is that I can not determine where my login information will go without examining the source of the login page. Sure, the form might be posted to a server using https. But, without examining the source of the login page, I won't be able to look at the certificate for the site to which my credentials have been sent until it's too late. It's still the case that if I retrieve the original login form via https, I have to examine the page source to see to which server the form will be posted. But I can examine the certificate of the site from which I got the form originally to determine whether this is a phishing attack. If the login form itself can be shown to have come from an AmEx server, I'm probably more comfortable trusting that my credentials are going to the right server. Do I completely misunderstand? - Ken . -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx [add: and other] unprotected login site
, though, so I accept that I can't have everything I want and I need to fulfill my obligations. Are we to expect less of AMERICAN EXPRESS? Of VERIZON? That's a non-starter as far as I'm concerned. If you want to have a life of excuses, you don't get to play with the grownups. Perry . -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Few comments on what Ivars Suba wrote: How to fight against phishing in organization enviroment? Quite easy- put SSL termination Proxy between client browser and SSL server: Sure, but: 1. This doesn't have any effect on non-SSL-protected sites (e.g. AmEx,... see `Hall of Shame`). And of course assumes users will notice the use of non-SSL-site... 2. This assumes that the problem is `untrusted site certificates`. Is it? Which CAs would you NOT accept anymore? In particular, would you now reject all `domain validated certificates` (about 25% of SSL sites I've heard)?? Much better imho to give the information to the user, possibly warning against (or blocking) certs from a CA you know to be bad. 3. This solution takes advantage of the fact that users don't have any idea which CA they trust... which is true but very bad, breaking the trust model. I think it is better to make the CA visible to the user (but in a way users can understand - I believe we have that with TrustBar). -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Ivars Suba responded to me: 1. This doesn't have any effect on non-SSL-protected sites (e.g. AmEx,... see `Hall of Shame`). And of course assumes users will notice the use of non-SSL-site... Vowww.. I didn't know that AmEx is not ssl protected ;)) Before user credentials are passed to site, site certificate are sent to client browser, then certificate are accepted/denied, ssl tunnel is established/access denied: As is clearly stated in messages you referred to, we all know Amex's site invoke SSL to encrypt the password. The problem is that a fake Amex site would not; and the user has no way to distinguish. Essentially, Amex site is secure against the (unlikely) eavesdropper, but not against the (much more likely) spoofer or the stronger (but possible) MITM. Is this site ssl proteceted? Shame Hall isn't so shamy ;) So, my claims in Hall of Shame remain. Or do you want to protect the Amex process? This will be interesting. ... Keep CA whitelist in SSL termination Proxy, and deny all others (including sef-signed site certs). You could of course do this filtering without also terminating the tunnel at your proxy. I agree that such filtering (without breaking the tunnel) is an advisable thing to do. 80% of users don't know what is the certificate. Imho, much better is trust this task to SSL termination proxy... I agree most users don't know what's a CA doing and what's a PK cert. But my intuition - and research - show that they can learn very quickly if we use simple words instead of jargon. In TrustBar, we display the name/logo of the site, followed by the words `identified by` and the name/logo of the CA. Our (limited) testing shows users understand this very well. And of course this does not prevent you from also blocking in a proxy any CAs you don't trust. Let the user decide among these you can't rule out. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Perry E. Metzger wrote: When I go to the SSL protected page, I can look at the URL and the lock icon in the corner before typing in my password. Bless you for being so careful. I, instead, look at the logo of the site and of the CA as displayed in TrustBar. This is much easier, and protects me from subtle changes in the URL e.g. homographic attacks, from spoofed address bars, and from certificates granted without proper validation, e.g. `domain validated` certificates. I would expect each security expert to use TrustBar (or other appropriate browser or browser extension - but check they don't send each URL to their server). When you type in your password BEFORE the SSL connection, by the time you realize that it went to the wrong place, it is way too late. If you realize it at all. Phisher can easily make you unaware of this. I admit that not everyone will check the URL and the lock icon, but at least it is *possible* to train people to do the right thing on that. There is no way, effectively, to train people to be safe given the way that Amex is set up. And no way you can protect your users by a proxy or a local TrustBar installation, which, as argued above, can protect reasonably well even naive or unsuspecting users. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Rephrased: Should login pages be protected by SSL - although it won'thelp most users?
Ole Kasper Olsen wrote: ... Amir Herzberg asked the question of should login pages be SSL encrypted. The flurry of discussion can be summerized as Yes... ... 2. Most people believe that a login page *should* be encrypted for web sites carrying important data. (e.g., financial, etc.) And many such sites are not protected, see `Hall of Shame` (link below) Encryption is not the point. Authentication is. A login page will never contain sensitive data anyway and as long as the form is submitted to a secure server, the data is encrypted just fine. A problem arises when a customer is tricked into entering credentials at an a bogus site. Absolutely. SSL/TLS has decent capability for providing authentication, however the sad truth is (as Michael Silk noted) that a vast majority of surfers do not understand nor read certificates. People don't even look at the URL (many (probably very successful) scams just rely on a semi-decent-looking link which points to an IP address). This is correct, given the current security indicators in browsers; I even have some empirical data to support this (but it is also common sense). However, the use of SSL may help _some_ users: -- The few users who carefully check the URL, padlock, certificate -- Users who install browsers/extensions providing improved security/identification indicators such as our TrustBar People in favor of unprotected login pages (mostly people in charge of them?) claim that both users groups above are negligible and do not justify using SSL. I disagree; for example, TrustBar is available thru multiple sites, and I have statistics only from http://addons.mozilla.org, and there I have over 25000 downloads. BTW this site also allows user feedback, which you are encouraged to leave, I read it carefully and I believe our next release will in fact take care of almost all concerns raised by users. And of course there are other improved security indicators solutions such as Netcraft, TrustToolBar (although I don't like their privacy invasion and overhead). This situation is also not helping convince browser folks to add the improved security UI to the browser (so I can get rid of developing TrustBar... have some other research projects to take care of!) -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Feature or Flaw?
Lance James wrote: ... https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame - done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then even SSL won't help it - it could end up sending the _wrong_ page, protected by SSL... And in this case I don't even think we can blame browser UI; the browser actually got this `bad` page from the server... Maybe I miss something? BTW, there is a new list focsed on such issues, at http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Feature or Flaw?
Lance James wrote: Amir Herzberg wrote: Lance James wrote: ... https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame - done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then It's not the new issue - it's the concern that frames with other SSL protect information is not being indicated to the user, thus you can encrypt data with another valid cert within a frame(s) and the user will only know of the main cert from the domain that is indicated by the address bar. Well, but I don't see that this has much to do with SSL, really. The problem is that the attacker is able to cause the server to send a page controlled (partially or fully) by the attacker. This should not happen. SSL is only supposed to ensure that the client got the page as the server sent it - and this does happen. Of course, this cannot protect against an infinite list of possible errors and vulnerabilities of the server: -- XSS attacks -- Defacement -- an employee intentionally putting a script to do something ... I think that your complaint/observation is that browsers normally warn when displaying a page which is partially protected and partially not, but may not complain when displaying a page protected by cert X, but including frame protected by cert Y. Well, this can be fixed, but I'm not sure this is really important. The problem is really the fact that the page was modified in the first place. Instead of including a protected (or unprotected) frame with the rogue code, the attack could have sent the rogue code directly from the compromised site. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. Steve, thanks. Not really much of surprise, is it? Clearly, a user who lets malware onto his/her PC, e.g. a VBscript in this case, has lost control and is open to such attacks. But... crypto and authentication, imho, are the best tools to prevent such malware from being installed. Yes, I know, this is far from the current situation, with corrupted PCs (Zombies) being a very large fraction (around a third?)... -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Pat Farrell wrote: On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote: I think that by eliminating the need for a merchant to learn information about your identity ... Wasn't that a goal of SET? As I recall, the goal of SET was to have a standard that was not invented by CyberCash. (I may be biased, I worked at CyberCash at the time). This is incorrect. The main politics around SET was the artificial `merger` of iKP (from IBM Mastercard) and STT (from Visa and MS). As far as I remember, CyberCash were involved but choose not to. They also did not disclose their protocol like the other proposals. I may be wrong about the CyberCash role, though, it was a while, and I don't think it matters so much... -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
simple (secure??) PW-based web login (was Re: Another entry in theinternet security hall of shame....)
Below is a proposal, based on the problem statement by Paul Hoffman: In many deployments of SSL first, then authenticate the user with a password, the site consists of two or more machines. Many or most high-traffic secure sites use SSL front-end systems to terminate the SSL connection, then pass the raw HTTP back to one or more web servers inside the network. The reason I bring this up is that the SSL server generally does not have access to the users' credentials. It could, of course, but in today's environments, it doesn't. Changing to TLS-PSK involves not only changing all the client SSL software and server SSL software, but also the what the SSL server's role in the transaction is. Excellent point. From which follows the question: can we improve the security of password-based web login, with less drastic changes - at least in the servers? Or is TLS-PSK the best/only way for us to improve pw-based web login? I think we can. For simplicity and concreteness, let's say we have the following architecture: regular SSL-supporting client and server, and behind the SSL server we have a web server with the improved pw-login mechanism. We want to support some `improved pw-login clients`, let's say these will be regular browsers with an extension such as (a new version of) TrustBar. Client and server begin with SSL `as is`. Now, the web server sends over this SSL-protected page a login page. Browsers without the extension, will handle it as a `classical` login form. But if the extension exists, it will detect that the server supports improved pw-based login, signalled e.g. with a META tag. The tag may also include number, denoted _Iterations_, which is the request number of hash-function iterations. Now, we need to consider two cases: a `nomad` user, vs. a `stationary` user. Stationary case is much nicer, and can use a single PW for all sites (`single sign on`), and/or biometric/device solutions (which I won't discuss). For a stationary user, the extension compares _Iterations_ and confirm it is at most one less than previous value of _Iterations_ used with this site. Also, the extension keeps a table r(PK) mapping the public key PK of each login site to an independant random value (we need this as real random value and can't derive them from the PW, to prevent dictionary attacks by fake sites). Now, using a single PW, extension computes for a site with given PK the value H(0)=h(PK, h(r(PK), PW). It then sends to the web server H(_Iterations_), by H(i)=h(H(i-1)) - the usual trick. This looks pretty good at first sight, so let's see who finds a big, unfixable hole in this simple design - which requires `only` support by a script on the web server (and of course an appropriate extension, but that's something we know how to do... and we can do some `secure UI` to deal with spoofing by other applications on the PC). Well, the case of nomad users - using a public terminal, without any secure storage facility - is less cool, imho, but there are some solutions there as well. The first is to use the old S/Key scratchpad method - user prints a few `one time passwords` for each of his login sites at home, to use on the road. Well, maybe not the most friendly solution, but will work (for known sites only). Notice that the `public PC` does not even need to have the extension for this low-tech solution to work (of course, this may allow a rogue site/PC to learn a specific OTP for a specific login site). Another solution is to use site-specific randomizers, i.e. user will provide the value for the r(PK) table - or, we can give to the user the values of r(PK) table... these do NOT have to be passwords, since their role is really to act as `salt` - make it impractical for sites to do dictionary attack on the `main` password. Maybe we can get away with this, and try to prevent users from using the same values for multiple sites... Of course, in this solution, user still enters her real PW to the hosting, public PC - and security fails against key loggers etc. Also this still requires us to use the extension on these machines... so I like the previous solution better. Ok, enough for now; now tell me what's wrong, etc It is definitely too simple to be any good. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Anti-fraud] simple (secure??) PW-based web login (was Re:Anotherentry in theinternet security hall of shame....)
Ian G wrote: Amir Herzberg wrote: For a stationary user, the extension compares _Iterations_ and confirm it is at most one less than previous value of _Iterations_ used with this site. (Minor point - if relying on incrementing Iterations, this may impact password sharing scenarios. Whether that's a good thing or a bad thing depends...) If by pw sharing you mean using same pw to login to multiple sites - the designs tries to solve this (securely) and so, the _Iterations_ counters should be kept for each site separately. Also, the extension keeps a table r(PK) mapping the public key PK of each login site to an independant random value (we need this as real random value and can't derive them from the PW, to prevent dictionary attacks by fake sites). I suspect this would not work so well in the (common enough?) cases where a site uses a farm of SSL boxes and certs; a couple of sites I've come across provide different certs every time (although admittedly I saw this with IMAP TLS not with browsing). Well, our experiance with TrustBar is contrary to that. We did not come across _any_ site that used different public keys in the different boxes. Of course, there is sense in using different key per box, to be able to identify broken-into box. But this requires many certificates and/or making browsers allow sites to sign secondary public keys; the first solution is expensive and ugly, the second requires fixing browsers, which is not very feasible... Can you find any real counterexample? [if there are few of these, I can add an appropriate workaround easily for them - no major change] Now, using a single PW, extension computes for a site with given PK the value H(0)=h(PK, h(r(PK), PW). Oops, that was mistyped: H(0)=h(r(PK), PW)). Server never sees PW, it stores only H(i) which is the latest it got; we can always begin a new chain by adding its endpoint. (Also, you are missing a closing parenthesis there so maybe your intent was other.) Yes - see above (Somewhat challenging your assumptions here) your design does not seem to cope with MITM. Do you see any MITM attack? Don't forget, this entire exchange is protected by `standard` SSL (using the server's public key PK). (But I may have misunderstood something...) I think you didn't notice that this entire exchange is all protected by the `standard`, server-auth SSL. So I just added client authentication, by sending the h^i(r(PK), PW) value, and the server can validate since it has h^{i-1}(r(PK), PW). Server never sees PW and cannot mount dictionary attack (if r(PK) has enough redundancy). iang ___ Anti-fraud mailing list Anti-fraud@lists.cacert.org http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud http://wiki.cacert.org/wiki/AntiFraudCoffeeRoom . -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Amazon's
Amazon have this lovely service: if you tell if you forgot your pw, they send you to: https://www.amazon.com/exec/obidos/self-service-forgot-password-get-email-done/104-2901457-0883904 where they ask you to confirm your identity... using 5 last digits of a credit card you used with them. Nice oracle to find last 5 digits... making it quite easy to find the full number. Not that anybody would bother. Still, I find it funny. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: simple (secure??) PW-based web login (was Re: Another entryin theinternet security hall of shame....)
Some clarification of the proposal: Initialization: === client has dedicated pw(server) to each server (today's situation). Client is supposed to be able to identify server based on the server's certificate etc., e.g. using TrustBar over regular browser. Client also installs the pw-based login extension, and provides it with a `master pw` MPW. Init1: client establishes SSL connection with server, to access login page. Let PK be the public key of the server. Init2: server sends login form, with indication of support for secure login Init3: extension identified this is a secure login, presents special window asking client to provide pw(server), and MPW if not provided yet, and to authenticate server (based on certificate). Init4: extension generates random number and saves it as R(PK) - random number for this particular server (as identified by its public key PK) Init5: extension sends to server, inside the SSL connection, a secure login submission, containing: 1. pw(server) as (only) current means of client authentication 2. h(h(MPW, R(PK))) - The value h(MPW, R(PK)) will be the `one time password` to be used in next login (we could also use a `hash chain` here but I removed it for simpicity and since it does not change much) Init6: server verifies pw(server) (old password) and stores the received h(h(MPW, R(PK))) as the hash of the new PW. It sends ack to the client (again protected by SSL). Init7: upon receipt of ack, client knows pw was updated. Regular login is pretty similar: = RL1: client establishes SSL connection with server, to access login page. Let PK be the public key of the server. RL2: server sends login form, with indication of support for secure login RL3: extension identified this is a secure login, presents special window asking client to provide MPW if not provided yet. RL4: extension sends to server, inside the SSL connection, a secure login submission, containing: 1. h(MPW, R(PK)) - The `one time password` 2. h(h(MPW, r')) - a new one-time-pw validator for next login R5: server verifies OTP (i.e. h(MPW, R(PK))), if OK, login is approved and saves new OTP validator h(h(MPW,r')). It sends ack to the client (again protected by SSL). R6: upon receipt of ack, client knows pw was updated: R(PK)=r'. This description glosses over dealing with failures, but this is not difficult; I also don't discuss how to support users of `public` PCs and changing PCs, solutions are possible. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Defending users of unprotected login pages with TrustBar 0.4.9.93
Most financial and other sensitive web sites use SSL/TLS to authenticate the server and protect data from eavesdropping and from modification by a Man In The Middle (MITM) adversary. However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. We can avoid using these sites, but this is a bit heavy penalty e.g. if it is your bank. We can also try to find an alternate login page which _is_ protected; in fact, we've found such alternate, protected sites for most ebanking login sites (see HoS). But this may be difficult for most (naive) users. So, we decided to add support for users of these unprotected sites in TrustBar. As of the latest version (0.4.9.93), available off my site (below), we added two such mechanisms: 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. 2. TrustBar allows users to assign a name or a logo to sites, protected or not (to help users identify fake sites). We now added a mechanism computes a hash of every unprotected site for which the user has assigned name/logo. TrustBar compares this hash on subsequent accesses to the same site. If the site is not modified in five subsequent accesses, TrustBar begins displaying `Same since date`; and when the site changes, TrustBar displays a warning. This can help users notice a fake version of their login page. Unfortunately, this mechanism does not work very well on most real-life login pages, since most of them contain a tiny bit of frequently-changing data such as date or `random` identifiers (mostly to identify a cookie-less client, we think). We are working on improving the mechanism so it will be tolerant to such tiny changes, without exposing the user to malicious changes. Please try it and tell us what you think of TrustBar in general and these features specifically. If you like it, please inform others, to protect them, help convince browsers to incorporate such features, and - last but not least for us - help us obtain more experimental data in our research on secure usability. Thanks! BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
John Gilmore wrote: Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: Of course, users can turn this off for one page or for all, but that's not answering yet John's comments below - I respond following them... Also: I am not crazy about this solution either, but I think the current situation, where very large banks insist on providing unprotected login pages, is even worse. I tried convincing them, and I must say few did change, e.g. Wells Fargo I think. I'll be happy to hear of better solutions (or do you think the current state is better?). 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. What if the list is signed by one or more authorities that users are willing to trust to this matter? Or just have the list in a trusted site - after all, if someone breaks Google, they can redirect much more than by attacking our server... A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. We are not redirecting to a trustworthy site (e.g., your bank is insecure, try that one instead...). We simply redirect to an SSL protected page of the same entity (bank) if we know one. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. Are you now against open source in general? After all, for this attack, Mozilla would be a much better target... In fact, since `everybody` uses Windows, any stupid program can redirect users to fake sites - and do much worse... Anyway - thanks for the feedback. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
David Wagner wrote: Amir Herzberg writes: However, quite a few of these sites invoke SSL/TLS only _after_ user has typed in her user name and pw, and clicked `submit`. This allows a MITM adversary to send a modified login page to the user, which sends the pw to the attacker (rather than encrypting it and sending to the site). See below link to a `Hall of Shame (HoS)` listing such sites. There are few things we can do about this. We can try to convince these sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few fixed, but most did not. But this isn't enough. The only way for a user to be secure against such attacks is to type in a https:-style URL into the address bar directly, or to load a https:-style URL from a bookmark. Why? What's your threat model? From the follow on, it seems you are concerned that even if the site's homepage say http://chase.com would redirect to https://chase.com, like etrade for instance do, this can be redirected by a MITM attacker. Similarly, if the homepage only contains a link to the https: protected login page, like most banks do e.g. Citibank, then again a MITM may redirect this to his own page. The user may not notice this change in address. In fact, with current browser UI, we know - by common sense and experiments - that almost all users will fail to notice such attacks. But our early experimental data with TrustBar seem to show that with improved UI, most users may be able to detect such spoofing attempts. Moreover, a MITM attack may be done even if the user types https://... A MITM may reply to the SSL connection itself (e.g. via DNS spoofing). True, the browser expects a certificate for say chase.com and now will get a cert for a different site, so the user gets a warning message; however, this is the sort of messages that users often click-away without reading and definitely without understanding. Furthermore, the attacker may even get a cert for the original address from one of the less-trustworthy CAs supported by the browser, in which case there is not even a warning - with current browser UI. TrustBar provides indicators which seem to allow most or at least many naive users detect such attacks (involving a non-trustworthy CA). Users have to always remember to type in https://www.bank.com; they must never use http://www.bank.com, or they will be insecure. Training users to follow this discipline is not a trivial task. Impossible task, imho. I'm not sure it is fair to blame this solely on the web sites changes to web browsers and/or web servers. So, a Hall of Shame seems a little over the top to me, since there is no obvious way that the web site could fix this on its own. Web sites should use SSL to protect their login forms (and redirect from http if user tries to use it). This does leave the possibility of users being redirected to other sites, but at least the site has done the best it can. Indeed, very few non-US banks expose their customers in this way. TrustBar's solution to this conundrum is a nice one. I like it. But it does require changing the web browser. Thanks, and yes, I agree, this requires browser change, I don't think we can avoid this. Users can currently use our extension, and we hope that as more and more do so, browers makers will add such features. One thing that web sites could do to help is to always make https://www.foo.com work just as well as http://www.foo.com, and then browser plug-ins could simply translate http://www.foo.com - https://www.foo.com for all sensitive sites. Of course, web site operators may be reluctant to take this step on performance grounds. Correct. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Adam Back wrote: I would think it would be safer to block the site, or provide a warning dialog. Before we do the first redirection, we do ask the user. However, since TrustBar is really part of our research on secure usability, we are aware that asking the user is a very problematic mechanism. Namely, we expect most users to simply click `yes` and forget about it. That's why I referred to it as default. Seems that I must repeat my request: a lot of you seem to agree that current browser security UI is broken, here are we developed a seemingly usable tool trying to fix it, takes 2-3 minutes to install - why don't you spend that time and then tell us how to improve (or to stop wasting our time as well as your 5 minutes)? Of course, what we'll really love (for our usability data) is for you also to get some non-expert users to try to use the system... someone who really uses e-banking and cares about the (very real threat) of spoofing/phishing... (This is what I was expecting when I started reading the head post; I was bit surprised at the interventionism to actually go ahead and fix the site, maybe that would be a better default behavior). Actually, from other feedback we got, I think we may extend the mechanism to be even more active, to protect also these pages which are not in our list of `known` unprotected login sites with a protected alternate site. What we may do is to archive a copy of these sites in your machine, and redirect you to the archived copy if/when the site `really` changes. This is a bit tricky as we need to ignore these small, insignificant changes that many of these sites do. btw Regarding unadvertised SSL equivalents, I have noticed if you login to gmail, you get SSL for login, but then http for web mailer. However if you edit the URL after login to https, it appears to work ok over SSL also. cool, this may also be something we can do for users (essentially requires us extending the auto-redirection features with wildcard functionality). -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: An overview of cryptographic protocols to prevent spam
John Gilmore wrote: I wrote an overview of Cryptographic Protocols to Prevent Spam, I stopped reading on page V -- it was too painfully obvious that Amir has bought into the whole censorship-list based anti-spam mentality. John, I'm disappointed; I expected you to be more tolerant. You got mad at me at page V which is still just reviewing the basic e-mail architecture related to spam. In this part, I explained what open-relays are and why people may try to disconnect from them, and described port-25 blocking which is common practice and necessary to protect domains from being blacklisted. I discuss blacklisting techniques and their problems much later, in section 5.5 (page XXV). I discuss there, albeit briefly, false positives, abuse, and collateral damage. I agree about the importance of clarifying these concerns, and will try to improve this. Frankly, however, I think you were a bit trigger-happy to conclude that I `bought-into` the censorship, black list approach. May I recommend that you ask first, shoot later? We had some discussions on this and while we may have differences, I thought you know I care a lot about freedom of speech. And btw, yes, as users of some (legitimate!) mail services, both me and several family memebers (e.g. children) were blocked by domain blacklists... When this happened to my 7 year old child, I had to forward his answers to a magazine for him. I once almost lost a consulting engagement to blocked email. And Ross Anderson once had to resort to asking Adi to call me on the phone to deliver a message, since a crazy mail filter here (Bar Ilan Univ.) blocked his messages for weeks... And more incidents. So believe me I'm well aware of this problem. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: US Banks: Training the next generation of phishing victims
I probably wasted more time than anybody on this crazy topic, and in particular: 1. I keep `Hall of Shame` site of such unprotected login pages (even got me a DigiCrime title: Inter-Net Fraud League Commissioner!) 2. With others, we develop TrustBar, an improved security indicator toolbar for FireFox, which also tries to protect users of unprotected login pages, e.g. by automatically redirecting to protected pages when found. Some results/observations: 1. Few companies that had a dialog with me said their marketing/site design folks insist on login via the homepage, claiming this is so much better for consumers compared to a separate login page. I see this as a very very extreme case of `usability beats security`. 2. Same companies also claimed that using SSL on homepage is too much overhead. Extreme case of `performance beats security`. 3. One company responded (to my warning of their unprotected login and the fact I'm going to add them to `hall of shame`) by legal threats. Typical case of `pay lawyers a lot, to avoid doing things right`. 4. One company sent me coupons for free trades. Rare example, I'm afraid... -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
`Identified by` CA technique of TrustBar adopted by IE, other browsers...
IE 7 implements some of TrustBar and FF improvements to security indicators. Specifically, they now color-code the location bar and added, in SSL/TLS pages, the name of the site and the `Identified by` name of CA - like TrustBar. They do not yet implement some of our other mechanisms, including the petnaming (allowing users to select their own name or logo which will be automatically displayed on entering a specific site), and the `random training exercise attacks`. OTOH, at least regarding the last mechanisms, we definitely agree it is not yet ready for prime time (and hope soon to provide a better version of it). Some relevant links: http://blogs.msdn.com/ie/archive/2005/11/21/495507.aspx - IE developer describing the improved security UI, with some screen shots http://dot.kde.org/1132619164/ - KDE developer describes a meeting of developers of four major browsers (IE, FF, Opera, KDE) where they agreed to adopt these ideas http://AmirHerzberg.com/TrustBar - my page for info and downloads of TrustBar... TrustBar is a public domain, open source project. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DoS attack on The Million Dollar Homepage
I found the enclosed of some interest.. From: http://milliondollarhomepage.com/blog.php, The Million Dollar Blog, Tuesday 17th January 2006: Site downtime, DDoS attack I can confirm that MillionDollarHomepage.com has been subjected to a Distributed Denial of Service (DDoS) attack by malicious hackers who have caused the site to be extremely slow loading or completely unavailable since last Thursday, 12th January 2006. I can also confirm that a demand for a substantial amount of money was made which makes this a criminal act of extorsion. The FBI are investigating and I'm currently working closely with my hosting company, Sitelutions, to bring the site back online as soon as possible. More news soon. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
New version (0.9.97) of TrustBar - first from the new developer team
Hi, the TrustBar project is finally back on track, with a new team of developers. For these who are not familiar, TrustBar is an extension to FireFox, which identifies SSL/TLS protected sites by the certified organization name and `Identified by:` CA, or by a name/logo of the user's choosing (`petname`). The team now work on several exciting extensions such as how to defend also users of unprotected (non-SSL) web pages, but this will take some time. In the meanwhile, we have an improved version (0.9.97), which finally works nicely on both windows, MAC and Linux (as far as we tested); we also removed the `Hey` functionality which people really hated (but we learned a lot from it and a much changed version will appear in the future). To install, download from http://www.cs.biu.ac.il/~herzbea/TrustBar/Latest%20TB.xpi Or: http://www.cs.biu.ac.il/~herzbea/TrustBar/index.html#download Feedback will be most welcome! -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Paper summarizing new directions in protecting web users
I've summarized the current directions that our group is working on towards improving security for web users. I'll probably soon post it as HTML, but I'm terribly busy and so far just posted it in eCrypt as PDF, see at http://eprint.iacr.org/2006/083.pdf. We hope to soon be able to provide more details and working extension(s) implementing these ideas - we are working on these. We would love your feedback, and look forward to cooperate with _any_ browser vendor, or security company (anti-virus, CA, etc.) that is interested in pursuing these exciting opportunities. Abstract. We describe the current state of web security, and identify the main problems. We then present proposals for improvements, including: secure site identification widget; secure and convenient `single click logon`; improved validation certificates; and using public-key signatures and automated resolutions and penalties, to defend against malicious content including malware. I'll appreciate your comments, suggestions and corrections. BTW: I'll be in NYC all of next week, for the W3C Workshop on Transparency and Usability of Web Authentication; in particular I'll visit (and present) in Columbia univ. this Friday and in IBM Watson on next Tuesday - so if any of you are around, I'll love to see you. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: length-extension and Merkle-Damgard hashes
Travis H. wrote: So I was reading this: http://en.wikipedia.org/wiki/Merkle-Damgard It seems to me the length-extension attack (given one collision, it's easy to create others) is not the only one, though it's obviously a big concern to those who rely on it. This attack thanks to Schneier: If the ideal hash function is a random mapping, Merkle-Damgard hashes which don't use a finalization function have the following property: If h(m0||m1||...mk) = H, then h(m0||m1||...mk||x) = h(H||x) where the elements of m are the same size as the block size of the hash, and x is an arbitrary string. Note that encoding the length at the end permits an attack for some x, but I think this is difficult or impossible if the length is prepended. This is the well known `classical attack` against the `naive Merkle's construction`, which does NOT use either an IV (for the 1st block), or `MD-strengthening` (append the length appropriately, etc.). Which is why hash functions use a fixed IV for the first block, or append length or otherwise encode the end block, or, most often, do both (as e.g. in SHA1, MD5). Prepending the length [without an IV], btw, is not necessarily a good solution. For example, let's assume, for simplicity, that the length (in blocks) is encoded as 20 bits, prepended to the first block; and say the input/output block length is L, and for simplicity, assume a compression function from 2L to L (so the minimal input length is 2L). Let TWO be the 20-bit encoding of the number 2, and let THREE be the 20-bit encoding of the number 3. Repeat until you find a collision (which you will, soon enough...): - Pick a random (2L-10)-bits string $r\in_R \{0,1\}^{2L-10}$. - Let H=h(THREE || r) - If TWO=[first 20 bits of H] then, for every block $x\in \{0,1\}^L$, we have $h(H||x)=h((THREE||r)||x), i.e. a collision. Best, Amir - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]