Slightly OT: encryption

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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

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



Re: Slightly OT: encryption

Colin McKinnon wrote:
Quoted text here. Click to load it

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,

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 @

Re: Slightly OT: encryption

Quoted text here. Click to load it

I'm only aware of the cookie mechanism for storing site-specific
information.  Some browsers have a mechanism for remembering a
username/password pair or a prior response to  web form, but it's not

I think cookies are your only option here.

DeeDee, don't press that button!  DeeDee!  NO!  Dee...

Re: Slightly OT: encryption

Colin McKinnon wrote:

Quoted text here. Click to load it

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

Site Timeline