Re: Hashing algorithm needed

2010-09-14 Thread Erwan Legrand
On Tue, Sep 14, 2010 at 13:29, Ian G wrote:
 On 14/09/10 2:26 PM, Marsh Ray wrote:

 On 09/13/2010 07:24 PM, Ian G wrote:

 1. In your initial account creation / login, trigger a creation of a
 client certificate in the browser.

 There may be a way to get a browser to generate a cert or CSR, but I
 don't know it. But you can simply generate it at the server side.

 Just to be frank here, I'm also not sure what the implementation details are
 here.  I somewhat avoided implementation until it becomes useful.

The French government has been doing this using Java applets for the
last decade (at least). This allows the happy French tax payers to
generate their own CSRs and have them automatically signed by the tax
administration in one swoop.

This might be the only large scale deployment of client-side
certificates in browsers I know of. (And I'd certainly like to hear
about others.)

Erwan Legrand

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: Effects of OpenID or similar standards

2009-11-09 Thread Erwan Legrand
On Mon, Nov 9, 2009 at 3:17 AM, Jerry Leichter wrote:
 On Nov 6, 2009, at 4:19 PM, Erwan Legrand wrote:
 Let's face it: most people use the same password for every single Web
 site they connect to. Starting from here, I can't see OpenID becoming
 much of a problem.

 While I'm sure this is widely believed, I wonder if it's really true.  Is
 anyone aware of research on the subject?

Not exactly, although I sure there was some research done on the
number of passwords people had to remember nowadays and how many they
were able to remember.

 Even if it's true to a large degree, the details may matter.  People may
 routinely use the same password for all their low value accounts, but come
 up with something better for their bank or other high value accounts.

For what it's worth (i.e. not much), in my own experience people who
actually do this qualify as nerds.

  Paradoxically, the *lack* of a standard for password quality may help here.
  High-value sites often place some requirement on the nature of passwords,
 but the requirements vary:  Letters and digits only; letters plus digits
 plus at least one special character - with the set of allowed special
 characters varying in pretty arbitrary ways; etc.  It's tough to come up
 with a single password that will be broadly accepted at such sites, and
 anything someone does come up with will be so inconvenient that it's
 unlikely to be something they'll want to use at low-value,
 any-password-accepted, sites.

Select any five letters long dictionary word of your choice, append 0
or 1 and you have a password one can reuse for almost all her
accounts. I've seen real people do just that.

 A widely-used single sign on system is certainly great from a usability
 point of view, and does actually have some positive effects on security:
  You no longer need to hand your actual password to sites programmed by
 someone whose background in security is minimal.  The downside is that you
 now have a single super-high-value password, the compromise of which would
 be very painful.

Agreed. This word, usability, is the key here. I used to be very
sceptical (to say the least) with regard to SSO systems. Then about
everyone around gained access to the Internet and the World Wide Web.
Then about every new Web site out there started requiring users to
create accounts. The likes of OpenID have their use in today's world.

Looking to this problem from another perspective, I'm yet to see any
sensitive Web site (such as a banking site) relying on OpenID for
authentication. But I must admit I haven't looked for one. Yet perhaps
someone on this list knows better?
Erwan Legrand

Simplicity is prerequisite for reliability.
-- E. W. Dijkstra

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: how to properly secure non-ssl logins (php + ajax)

2009-02-20 Thread Erwan Legrand

 Recently, on both the jQuery(.com) and PHP mailinglists, a question has
 arisen on how to properly secure a login form for a non-ssl web-application.
 But the replies have been get ssl.. :(

What makes you think these are ill-advised?

 I disagree, and think that with a proper layout of authentication
 architecture, one can really secure a login system without having the
 administrative overhead of installing SSL everywhere, and the monetary cost
 for a SSL certificate for each domain.

Well, it depends on how much security is enough for you. If the
threats you are concerned with encompass the threats mitigated by
SSL/TLS, then you should definitely use TLS. You could arguably use
Kerberos, SSH or IPSEC to achieve the same level of security, but that
would not be handy, since SSL/TLS is what is bundled in web servers
and browsers. Oh, and you don't necessarily have to buy a certificate
to Verisign to use SSL!

The only thing your scheme seems to achieve is protect your password
against eavesdroppers. But then, an eavesdropper could reuse your
cookie to hijack your session. Your protocol does not mitigate such
threats as session hijacking, MITM, phishing, HTTP cache poisoning and
the list goes on. And whatever the shortcomings of TLS might be, it
does mitigate these threats.

Now, if you threat model goes along the lines of :
 * The only asset I want to protect is my password (because I use the
   same password to access critical data hosted on other services!)
 * I don't care whether my session is compromised.
 * I don't care whether my data is captured by an eavesdropper.
Then your scheme might indeed be what you need. I did not give it more
than a quick look though. And I would suggest you reconsider in the
first place the reasons that made you reuse such a precious password.

I hope this last paragraph makes sense and you will forgive my use of sarcasm.
Erwan Legrand

Simplicity is prerequisite for reliability.
   -- E. W. Dijkstra

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to