Re: Hashing algorithm needed

2010-09-15 Thread Ben Laurie
On 15/09/2010 00:26, Nicolas Williams wrote:
 On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote:
 How do you deliver Javascript to the browser securely in the first
 place? HTTP?
 
 I'll note that Ben's proposal is in the same category as mine (which
 was, to remind you, implement SCRAM in JavaScript and use that, with
 channel binding using tls-server-end-point CB type).
 
 It's in the same category because it has the same flaw, which I'd
 pointed out earlier: if the JS is delivered by normal means (i.e., by
 the server), then the script can't be used to authenticate the server.

That's one of the reasons I said it was only good for experimenation.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-15 Thread Ben Laurie
On 14/09/2010 21:16, Marsh Ray wrote:
 On 09/14/2010 09:13 AM, Ben Laurie wrote:
 Demo here: https://webid.digitalbazaar.com/manage/
 
 This Connection is Untrusted

So? It's a demo.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-14 Thread Ian G

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.


Marsh's notes +1 from me.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-14 Thread Marsh Ray

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

On 11/09/10 6:45 PM, f...@mail.dnttm.ro wrote:


Essentially, the highest risk we have to tackle is the database.
Somebody having access to the database, and by this to the
authentication hashes against which login requests are verified,
should not be able to authenticate as another user. Which means, I
need an algorithm which should allow the generation of different
hashes for which it can be verified that they stem from the same login
info, without being able to infer this login info from a hash. This
algorithm is the problem I haven't solved yet. Other than that, I see
no way of protecting against a dictionary attack from somebody having
direct access to the database.


flj, I appreciate your systematic and conscientious engineering 
approach. But I haven't heard anything in your requirements that make it 
sound like a journey outside of well established protocols is justified 
here.


There are a few experienced people around here who could probably design 
come up with a new custom scheme and get it right the first time. But 
the history of most (even professionally-designed) new security 
protocols usually includes the later discovery of serious weaknesses.



I don't recall the full discussion, but what you described is generally
handled by public key cryptography, and it is built into HTTPS.

Here's my suggestion:


+1

I have a similar setup going in a reasonably big production environment 
and it's working great.



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.



1.b. record the client cert as the authenticator in the database.



2. when someone connects, the application examines the cert used, and
confirms the account indicated.


Note that you can get the full client cert presented by the web server 
and compare it (or a sufficiently long :-) hash of it) directly with 
what you have in the database. There may be no need to check signatures 
and so on if your server-side is centralized.



If an unknown cert, transfer to a
landing page.
2.b note that there is no login per se, each request can as easily check
the client cert listed by Apache.


Most apps will want to ask the human to authenticate explicitly from 
time to time for one reason or another.



3. you just need some way to roll-over keys from time to time. Left for
later.


Make sure you have at least some way of revoking and renewing a client 
certs, even if it's a code update. Just on the outside chance that, say, 
the keys got generated by Debian Etch's RNG or something.



3.b There are some other bugs, but if the approximate scheme works...


Three more recommendations:

Don't put anything sensitive in the X509 cert. Just a minimal userid or 
even random junk. You're just looking it up in a database.


Disable TLS renegotiation unless you control both the clients and the 
servers and can ensure they're all patched for CVE 2009-3555. Don't 
expect to be able to use renegotiation to hide the contents public 
cert, that never worked against an active attacker anyway.


Use a separate dns name for the https site that accepts client certs 
from the one that does not. The reason is that the client cert will have 
to be requested on the initial handshake. Requesting a client cert will 
cause many browsers to pop-up a dialog. Not something you want on your 
secure home page.


Again this is a good scheme, it's the way SSL/TLS has been intended to 
be used for authenticated clients since SSLv3. It even offers additional 
protections from the server's perspective, too: the server is no longer 
forced to transitively trust the union of all trusted root CA certs of 
all allowed clients in order to prove the non-existence of a 
man-in-the-middle.


- Marsh

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-14 Thread Ben Laurie
On 14/09/2010 12: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.

FWIW, you can get browsers to generate CSRs and eat the resulting certs.
The actual UIs vary from appalling to terrible.

Of some interest to me is the approach I saw recently (confusingly named
WebID) of a pure Javascript implementation (yes, TLS in JS, apparently),
allowing UI to be completely controlled by the issuer. Ultimately this
approach seems too risky for real use, but it could be used to prototype
UI, perhaps finally leading to something usable in browsers.

Slide deck here: http://payswarm.com/slides/webid/#(1)

(note, videos use flash, I think, so probably won't work for anyone with
their eye on the ball).

Demo here: https://webid.digitalbazaar.com/manage/

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-14 Thread Erwan Legrand
On Tue, Sep 14, 2010 at 13:29, Ian G i...@systemics.com 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 majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-14 Thread Marsh Ray

On 09/14/2010 09:13 AM, Ben Laurie wrote:

On 14/09/2010 12: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.


FWIW, you can get browsers to generate CSRs and eat the resulting certs.
The actual UIs vary from appalling to terrible.

Of some interest to me is the approach I saw recently (confusingly named
WebID) of a pure Javascript implementation (yes, TLS in JS, apparently),
allowing UI to be completely controlled by the issuer.


First, let's hear it for out of the box thinking. *yay*

Now, a few questions about this approach:

How do you deliver Javascript to the browser securely in the first 
place? HTTP?


How do you get the user to save his private key file? Copy and paste?

How does the proper Javascript later access the user's private key securely?

How do they securely wipe memory in Javascript?

How do they resist timing attacks? In practice, an attacker can probably 
get the browser to repeatedly sign random stuff with the client cert 
even while he's running his own script in the same process.



Ultimately this
approach seems too risky for real use, but it could be used to prototype
UI, perhaps finally leading to something usable in browsers.


A sad indictment of browser vendor user interface priorities.


Slide deck here: http://payswarm.com/slides/webid/#(1)

(note, videos use flash, I think, so probably won't work for anyone with
their eye on the ball).

Demo here: https://webid.digitalbazaar.com/manage/


This Connection is Untrusted

- Marsh

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-14 Thread Nicolas Williams
On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote:
 On 09/14/2010 09:13 AM, Ben Laurie wrote:
 Of some interest to me is the approach I saw recently (confusingly named
 WebID) of a pure Javascript implementation (yes, TLS in JS, apparently),
 allowing UI to be completely controlled by the issuer.
 
 First, let's hear it for out of the box thinking. *yay*
 
 Now, a few questions about this approach:
 
 How do you deliver Javascript to the browser securely in the first
 place? HTTP?

I'll note that Ben's proposal is in the same category as mine (which
was, to remind you, implement SCRAM in JavaScript and use that, with
channel binding using tls-server-end-point CB type).

It's in the same category because it has the same flaw, which I'd
pointed out earlier: if the JS is delivered by normal means (i.e., by
the server), then the script can't be used to authenticate the server.

And if you've authenticated the server vi HTTPS (TLS) then you might as
well just POST the usernamepassword to the server, since the server
could just as well send you a script that does just that.

This approach works only if you deliver the script in some out-of-band
manner, such as via a browser plug-in/add-on (hopefully signed [by a
trustworthy trusted third party]).

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-09 Thread James A. Donald

On 2010-09-09 6:35 AM, Ben Laurie wrote:

What I do in Nigori for this is use DSA. Your private key, x, is the
hash of the login info. The server has g^x, from which it cannot
recover x,


Except, of course, by dictionary attack, hence g^x, being low
entropy, is treated as a shared secret.

and the client does DSA using x.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-09 Thread Ben Laurie
On 9 September 2010 10:08, James A. Donald jam...@echeque.com wrote:
 On 2010-09-09 6:35 AM, Ben Laurie wrote:

 What I do in Nigori for this is use DSA. Your private key, x, is the
 hash of the login info. The server has g^x, from which it cannot
 recover x,

 Except, of course, by dictionary attack, hence g^x, being low
 entropy, is treated as a shared secret.

Indeed, if it is low entropy (I don't think you can assume it is,
though I'll readily agree it is likely to be), then it is subject to a
dictionary attack.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Hashing algorithm needed

2010-09-08 Thread flj
Hi.

Just subscribed to this list for posting a specific question. I hope the 
question I'll ask is in place here.

We do a web app with an Ajax-based client. Anybody can download the client and 
open the app, only, the first thing the app does is ask for login.

The login doesn't happen using form submission, nor does it happen via a known, 
standard http mechanism.

What we do is ask the user for some login information, build a hash out of it, 
then send it to the server and have it verified. If it checks out, a session ID 
is generated and returned to the client. Afterwards, only requests accompanied 
by this session ID are answered by the server.

Right now, the hash sent by the browser to the server is actually not a hash, 
but the unhashed login info. This has to be changed, of course.

What we need is a hashing algorithm that:
- should not generate the same hash every time - i.e. should includen something 
random elements
- should require little code to generate
- should allow verification of whether two hashes stem from the same login 
data, without having access to the actual login data

We need to implement the hashing algorithm in Javascript and the verification 
algorithm in Java, and it needs to execute reasonably fast, that's why it has 
to require little code. None of us is really into cryptography, so the best 
thing we could think of was asking for advice from people who grok the domain.

The idea is the following: we don't want to secure the connection, we just want 
to prevent unauthenticated/unauthorized requests. Therefore, we only send a 
hash over the wire and store it in the database when the user changes his 
password, and only send different hashes when the user authenticates later on. 
On the server, we just verify that the stored hash and the received hash match, 
when an authentication request arrives. Cleartext passwords aren't stored 
anyway, and don't ever travel over the wire.

However, we could not imagine a reasonable algorithm for what we need until 
now, and didn't find anything prefabricated on the web. Therefore we ask for 
help.

br,

flj

PS: reusing the session ID is of course a security risk, since it could allow 
session hijacking. We're aware of this, but don't intend to do anything about 
it other than warn customers/users. Since it's a web application, its client 
code is open, and anybody being able to watch the connection can deduce 
whatever is needed to hijack the session, no matter what algorithm is used, 
unless the connection is encrypted right from the start. Connection security is 
however outside the scope of the web application. We can't encrypt 
communication in Javascript for efficiency reasons, it has to be done in a 
lower layer (VPN or SSL, for example). It may in theory work using a preshared 
key, but it's not reasonable to believe that the application users will be able 
to cope with such a mechanism.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-08 Thread Ben Laurie
On 8 September 2010 16:45, f...@mail.dnttm.ro wrote:

 Hi.

 Just subscribed to this list for posting a specific question. I hope the 
 question I'll ask is in place here.

 We do a web app with an Ajax-based client. Anybody can download the client 
 and open the app, only, the first thing the app does is ask for login.

 The login doesn't happen using form submission, nor does it happen via a 
 known, standard http mechanism.

 What we do is ask the user for some login information, build a hash out of 
 it, then send it to the server and have it verified. If it checks out, a 
 session ID is generated and returned to the client. Afterwards, only requests 
 accompanied by this session ID are answered by the server.

 Right now, the hash sent by the browser to the server is actually not a hash, 
 but the unhashed login info. This has to be changed, of course.

 What we need is a hashing algorithm that:
 - should not generate the same hash every time - i.e. should includen 
 something random elements
 - should require little code to generate
 - should allow verification of whether two hashes stem from the same login 
 data, without having access to the actual login data

 We need to implement the hashing algorithm in Javascript and the verification 
 algorithm in Java, and it needs to execute reasonably fast, that's why it has 
 to require little code. None of us is really into cryptography, so the best 
 thing we could think of was asking for advice from people who grok the domain.

Well, you can't always get what you want.

What I do in Nigori for this is use DSA. Your private key, x, is the
hash of the login info. The server has g^x, from which it cannot
recover x, and the client does DSA using x.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Hashing algorithm needed

2010-09-08 Thread Chris Palmer
f...@mail.dnttm.ro writes:

 The idea is the following: we don't want to secure the connection,

Why not?

Using HTTPS is easier than making up some half-baked scheme that won't work
anyway.


-- 
http://noncombatant.org/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com