Hi,

Interesting idea. If I understand you correctly, its equivalent to the
following:

Every link and form on the generated pages contain
a parameter with some arbitrary text, and the client executes
javascript onclick() or onsubmit() that encrypts this text and issues the
request.

The server then only serves a page if the arbitrary text was correctly
encrypted. The server must maintain a record of the links/forms its
written and the associated text it issued. The server needs to know the
users password (to derive the encyrption key), but the password never
traverses the wire.

Say,
[A-Za-z0-9./] = 64 possible values per character
11 characters = 2^66 > 2^64
22 characters = 2^132 > 2^128

        1.8x10^19 = 2^64
        3.4x10^38 = 2^128

        7.4x10^19 = 64^10 = 2^6^11 = 2^66
        5.4x10^39 = 64^22 = 2^6^22 = 2^132

So, an 11 character password, chosen from the characters above,
would be (slightly) better than a 64 bit key, and using 22
characters would be (slightly) better than a 128 bit key.

The password can act as a 'shared secret' and serve as the encryption
key (with whatever transformations are necessary).

This, obviously, does not protect against people snooping on the session,
but would stop an attacker from hijacking the transactions.

The problem would be password complexity. Enforcing 11 character, random,
passwords may be a problem. Certainly for 128bit style security, using 22
characters would kill most users. Although there may be way to achieve
that complexity, by using for example two passwords and a pin (of the
correct length). Easier to remember two semi-complex things than one
(insert disclaimer here). But thats not really your question.

By hashing the password, adding a sessionid, and hashing the result
you dont gain anything. The 'key' is still as complex as the password.

Sounds like a valid approach. Cant help you with the vb/ocx technical
details tho.

- foob

On Tue, 26 Mar 2002, Mike Cahn wrote:

> Hi all I'm trying to come up with a way to protect a web session from
> hijacking and data tampering in transit, and also make dictionary
> attacks as difficult as possible. Data confidentiality is not an
> issue. I want to avoid SSL.
>
> We know that the web client will be running under Windows (probably NT
> or 2000). I want to generate a shared secret key without passing it
> between the server and client. Here's my proposed approach, which is
> challenge/response followed by request signing.
>
> 1. Server generates random challenge text and random session id and
> stores these in a database, along with a timestamp (used for expiring
> sessions). It then sends the requested login page to the client with
> an embedded OCX, and the random challenge text and session id. [As
> per the recent thread, I'll obvioulsy have to be careful how these
> "random" values are generated.]
>
> 2. Client enters login credentials and clicks a button. Javascript
> code hashes the password (MD5), adds it to the session id, hashes the
> result, and passes this into the OCX, which invokes the Windows
> CryptoAPI to generate a key. This key I propose to use as the shared
> secret session key. The random challenge text is next fed into the
> OCX and encrypted using the new key. Encryption is via the Windows
> CryptoAPI. Client then sends the plaintext userid and sessionid, and
> the encrypted text, back to the server.
>
> 3. Server looks up the userid and retrieves the hashed password from
> the database. It goes through the same operations and generates the
> key, and then uses it to decrypt the random text.
>
> 4. Assuming they match, server can now store the key in the same table
> where it stored the sessionid and random text, for use in all
> communciations in the current session. Server then generates a
> one-off "request" key, saves this in the same table, and includes it
> in the next page it serves the client.
>
> 5. When the client submits its next request, it will include its
> normal plaintext session id and request text, along with a hash of
> (session key + request key + actual request text). Server can then do
> same hash and authenticate user and validate contents of request
> simultaneously.
>
> 6. All subsequent responses from the server provide a newly generated
> "request" key. I'm doing this so a cracker can't lift a validated
> request and simply replay it to the server. However I think this
> might cause problems if a user submits a page twice or clicks Stop
> after submitting a page - he might no longer have a valid request key.
>
> I'd be interested in hearing where the holes are in this.
>
> In terms of implementation, if I could get away from using an OCX and
> the CryptoAPI, I'd be happier. Is there Javascript that will do
> something similar?
>
> Mike
>
> Mike Cahn
> Research and Development
>
> PHOENIX TECHNOLOGY GROUP
> 32/34 Castle Street
> Dublin 2
> Tel: +353 1 6707722
> Fax: +353 1 6707721
>
> mailto:Mike.Cahnphoenix.ie
> http://www.phoenix.ie
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]