Slightly OT: encryption

Hi all,

I've reached the limits of my knowledge and was wondering if anyone out
there is better informed.

I'm trying to setup a system of secure encryption for exchanges between
browser and server WITHOUT using SSL. I have hashing (MD5) at both ends and
symmetric encryption (TEA). If anybody knows a SECURE asymmetric encryption
algorithm which works with javascript - do let me know.


I have a reasonably secure logon system - server sends challenge and stores
MD5(challenge+password). Browser sends back MD5(challenge+password).

It occurred that if I could store the password at the browser end, I could
use it as the encryption key for future exchanges. But where to store it?

I could put it in a cookie, but that gets sent in the clear with each
request.

If I put it in a secure cookie or a cookie with an obfusticated path it
wouldn't get sent back, but the browser can't read it either!

Is there anywhere I can store a value using javascript which is readable by
javascript but not normally sent back to the server?

Alternatively, is there any information available in Javascript which is not
normally sent back to the server? (if so I can use this to encrypt the
password before storing it in the cookie)?

(I realise that an XSS vulnerability would expose the password, but I'm not
looking to do serious stuff like credit card details).

TIA,

C.

Colin McKinnon wrote:
[snip]
> If I put it in a secure cookie or a cookie with an obfusticated path it
> wouldn't get sent back, but the browser can't read it either!
>
> Is there anywhere I can store a value using javascript which is readable by
> javascript but not normally sent back to the server?

If you're willing to put up with a frameset, you could keep data in a
variable in another frame that stays open. It could be a bit fragile,
though.

Unless this is a hobby project, I suspect you're better off just using
https. If this is a hobby project, being better off isn't the point. :)

-- brion vibber (brion @ pobox.com)

[Followup-to: comp.lang.php, comp.os.linux.security]
Colin McKinnon wrote:
<snip>
> Is there anywhere I can store a value using javascript which is
readable by
> javascript but not normally sent back to the server?

I guess, two solutions:
1. Use frameset and stuff the hash to the JavaScript variable in
another (static) frame; and then reuse that.
2. Use application like interface with XMLHttpRequest and div based
rendering container--so that the page won't get refreshed (so that you
may use the JavaScript variables), but you only paint/render the
rendering container. Last time when I checked Gmail, it used similar
interface.

<snip>
> (I realise that an XSS vulnerability would expose the password, but
I'm not
> looking to do serious stuff like credit card details).

In the world of 1's and 0's, there is no bulletproof solution. Also,
you may not be in a position to convince the end users about your two
way encryption solution when you're doing in http. (FWIW, IIRC, it is
quite illegal to get credit card details even over SSL on your site.)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Followup-to: comp.lang.php, comp.os.linux.security]
Colin McKinnon wrote:

<snip>

> Is there anywhere I can store a value using javascript which is
readable by
> javascript but not normally sent back to the server?

I guess, two solutions:
1. Use frameset and stuff the hash to the JavaScript variable in
another (static) frame; and then reuse that.
2. Use application like interface with XMLHttpRequest and div based
rendering container--so that the page won't get refreshed (so that you
may use the JavaScript variables), but you only paint/render the
rendering container. Last time when I checked Gmail, it used similar
interface.

<snip>

> (I realise that an XSS vulnerability would expose the password, but
I'm not
> looking to do serious stuff like credit card details).

In the world of 1's and 0's, there is no bulletproof solution. Also,
you may not be in a position to convince the end users about your two
way encryption solution when you're doing in http. (FWIW, IIRC, it is
quite illegal to get credit card details even over SSL on your site.)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Colin McKinnon wrote:

> I'm trying to setup a system of secure encryption for exchanges between
> browser and server WITHOUT using SSL. I have hashing (MD5) at both ends
> and symmetric encryption (TEA). If anybody knows a SECURE asymmetric
> encryption algorithm which works with javascript - do let me know.

If this is for fun, more power to you!

If you have real customers who need real security, start by
enumerating your security requirements: if you haven't stated
where you're trying to go, you'll never know whether you've
gotten there. When you seek "security", are you seeking
authentication, or secrecy? If authentication, in one direction,
or both? Who is the adversary, and what are his resources?
Can he intercept and modify messages between the browser and
the server? Can he intercept multiple sessions?

Your chances of arriving at something as secure as SSL, or
even as secure as SSL Version 1, which was superseded for
good reason, are comparable to my chances of being elected
Governor of California. See Bruce Schneier's essay,
"Why Cryptography Is Harder Than It Looks", at
http://www.schneier.com/essay-037.html. If your customers
really need security, and if you really respect that need,
then at least have your design reviewed by a cryptologist
before you get too far into implementation.

--
Peter Pearson
To get my email address, substitute:
nowhere -> spamcop, invalid -> net