| deadmike on Mar 9, 1999 at 7:05:17 AM (# 2)
Scott,
As a matter of fact, I recently wrote a complete bucketed hashtable in JavaScript, since I've not seen any articles, anywhere on serious computing data structures in JavaScript. So, I wrote a simple bucketed hashtable object which worx extremely well.
I was planning on contributing an article within the next few weeks, to coincide with the release of the website for which it is being used (so you can see it in action).
As part of that code, I have three fast & simple hash algorithms. I certainly don't want to steal the punch away from the article I have planned. ;^)
But, please email me, if you are interested. :)
Bue skies,
- michael b. vederman
a.k.a. Dead Mike
javascript@deadmike.com
http://www.deadmike.com
deadmike on Mar 9, 1999 at 3:31:50 PM (# 3)
OK, I just re-read your topic header and now understand more clearly what you want.
You want an encryption/decryption algorithm (which is different than a hashing algorithm)...
My bad for not reading your text to get a clearer idea. I zeroed in on hashing function (which I have, but not an encryption/decryption algorithm).
You could always just use ROT13. :)
Sorry for the confusion, but expect a submission sometime soon (you do take submissions, don't you?)
- mike
deadmike on Mar 9, 1999 at 3:40:25 PM (# 4)
Boy, I wish we could edit our previous messages, so I pre-apologize for yet another post (YAP). Yes, after this I will stop YAPping. ;^)
======
Scott,
Depending on how you would like to implement your encryption/decryption; with a sufficiently good hashing algorithm, you don't need to decrypt the existing password, you only need to hash the clear password and see if it matches the cookie stored hash value. This is the way many password files are handled.
A sufficiently good hashing algorithm with a large, prime number mask will provide good dispersion of hash values so someone could not happen upon another password that hashes to the same value.
If this is what you have in mind, then, yes, I have something you might want to use. ;^)
Take your pick, I have something or I don't. :)
- mike
dxjohnso on Mar 9, 1999 at 5:27:12 PM (# 5)
I agree with the first poster, CharlieP. The encryption is irrelevant. Any hacker "sniffing" the net or otherwise gaining access to your cookie can duplicate the cookie thereby masquerade as someone else (encrypted password or not).
I'd step back for a moment and ask exactly what it is that your protecting, or are you really protecting anything at all? In other words, is the logon an identification or an entitlement?
If you plan to provide "special" privileges to specific registered visitors, the logon becomes an entitlement. Entitlements usually require more stringent security; which violates your directive concerning simplicity and ease of use. Besides, there are numerous security tools that will do this for you; so there is no reason to reinvent the wheel.
If you provide the same privileges for all registered visitors, the logon is identification only. Identifiers are so ubiquitous on the Internet that again, you ought not reinvent the wheel. Upon first authentication, simply put a "visitor ID" in your cookie for next time. (This should be optional -- i.e. the visitor should request auto-logon). If the cookie is lost or expires, reinstate it again after authentication.
K.I.S.S.
Scott Isaacs on Mar 9, 1999 at 7:16:03 PM (# 6)
I have a simple goal - I know many user's reuse the same password from site to site. Therefore, I am more concerned about storing the password in the cookie. I am less concerned about someone copying a cookie and masquarading as another user (the likelihood is of this is pretty low).
On further thought, I am looking for a way to create a unique, random identifier that I can use in the cookie. There are two "unique" fields in the database - the user-name and user-id number. I assume there is probably a way I can combine this information with their password to generate a unique key. I want to be able to do a test on the "key" to ensure that it maps back to the password. So I assume the cookie would consist of two values - the user # and the unique key which I can use to decrypt and compare to the user's password on the server. This also ensures that someone changing a password gets a new unique key (and to change a password you need to know the original password)
Hopefully this is clear... I definitely want to keep this simple but want a minimal level of security.
Thanks,
Scott
ps - if you haven't figured out, my knowledge of encryption is fairly limited :-)
Scott Isaacs on Mar 9, 1999 at 7:16:54 PM (# 7)
DeadMike -
Yes we accept submissions. When you are ready, please e-mail it directly to scotti@insideDHTMl.com.
Thanks! -Scott
Scott Isaacs on Mar 10, 1999 at 9:09:37 PM (# 8)
Thanks to everyone who responded. A friend of mine gave me a pretty good algorithm for encrypting passwords. For the curious, you can examine your cookie after enabling the smart-login feature and examine the key cookie.
Please let us know if you experience any problems with this feature or if you feel there is an issue with our encryption (for various reasons, I am not going giving the algorithm away so please don't ask).
-Scott
| 
Password hash algorithm