Re: Maybe It's Snake Oil All the Way Down

2003-06-03 Thread Amir Herzberg
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

2003-07-08 Thread Amir Herzberg
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

2003-11-16 Thread Amir Herzberg
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

2003-12-18 Thread Amir Herzberg
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

2003-12-18 Thread Amir Herzberg
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)

2003-12-23 Thread Amir Herzberg
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)

2003-12-28 Thread Amir Herzberg
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)

2003-12-30 Thread Amir Herzberg
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??)

2004-01-02 Thread Amir Herzberg
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

2004-05-25 Thread Amir Herzberg
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

2004-06-15 Thread Amir Herzberg
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...

2004-07-04 Thread Amir Herzberg
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...

2004-07-08 Thread Amir Herzberg
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...

2004-07-09 Thread Amir Herzberg
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 ....

2004-07-11 Thread Amir Herzberg
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...

2004-07-11 Thread Amir Herzberg
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

2004-07-13 Thread Amir Herzberg
[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...

2004-07-14 Thread Amir Herzberg
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

2004-07-22 Thread Amir Herzberg
 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

2004-07-22 Thread Amir Herzberg
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)

2004-08-16 Thread Amir Herzberg
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 ?

2005-02-02 Thread Amir Herzberg
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 ?

2005-02-04 Thread Amir Herzberg
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 ?

2005-02-06 Thread Amir Herzberg
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...)

2005-02-09 Thread Amir Herzberg
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...)

2005-02-10 Thread Amir Herzberg
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...)

2005-02-10 Thread Amir Herzberg
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...)

2005-02-10 Thread Amir Herzberg
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?

2005-03-20 Thread Amir Herzberg
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

2005-03-20 Thread Amir Herzberg
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...)

2005-05-20 Thread Amir Herzberg
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

2005-05-30 Thread Amir Herzberg
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

2005-05-31 Thread Amir Herzberg
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

2005-05-31 Thread Amir Herzberg


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

2005-06-01 Thread Amir Herzberg

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

2005-06-07 Thread Amir Herzberg

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 ?)

2005-06-09 Thread Amir Herzberg
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

2005-06-09 Thread Amir Herzberg
, 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

2005-06-09 Thread Amir Herzberg

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

2005-06-09 Thread Amir Herzberg

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

2005-06-09 Thread Amir Herzberg

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?

2005-06-23 Thread Amir Herzberg

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?

2005-07-05 Thread Amir Herzberg

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?

2005-07-06 Thread Amir Herzberg

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

2005-07-11 Thread Amir Herzberg

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

2005-07-14 Thread Amir Herzberg

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....)

2005-09-14 Thread Amir Herzberg

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....)

2005-09-14 Thread Amir Herzberg

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

2005-09-14 Thread Amir Herzberg


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....)

2005-09-15 Thread Amir Herzberg

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

2005-09-19 Thread Amir Herzberg

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

2005-09-20 Thread Amir Herzberg

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

2005-09-20 Thread Amir Herzberg

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

2005-09-22 Thread Amir Herzberg

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

2005-09-26 Thread Amir Herzberg

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

2005-10-14 Thread Amir Herzberg
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...

2005-11-30 Thread Amir Herzberg
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

2006-01-18 Thread Amir Herzberg

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

2006-01-22 Thread Amir Herzberg
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

2006-03-08 Thread Amir Herzberg

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

2007-02-03 Thread Amir Herzberg

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]