Please try changing the message
| User defined message |
try
| Enter a message |
To set the "user defined message" above, fill in a new message in the box,
and Enter the password, secret, in the password box. Leave the
time stamp alone. To send, click Calculate Hash then Sumbit.
| Explanation |
This page features a message which can be viewed by anyone, but can only by set by someone who knows the authorization password. Perhaps this could be useful as a 'whereabouts' message, or you could develop the idea further for remote administation, logins, etc. In a real implementation, you'd hide the time stamp, and automatically calculate the hash on submitting.
When you click Calculate Hash, the password is replaced by the MD5 of the message, time stamp and password, concatonated together. When you click submit, the message, time stamp and hash are sent to the server. It already knows the password, so it can works out what the hash should be, using the Perl MD5 module. The received hash will only match this if the password is correct. The password itself is never transmitted, so an eavesdropper can't get it.
If you click Submit without clicking Calculate Hash then
the password is transmitted unencrypted. This will still set the message,
but you'll get a warning because the password could have been intercepted.
This means that the system works, but insecurely, if JavaScript is disabled.
If you want to mandate encryption, the best way is to have the password on
a separate form to the data. Have a JavaScript onsubmit function
for the main form that grabs the password from the other form, performs the
hash, and puts it on the main form. Even if JavaScript is disabled, the password
won't be submitted in the clear. Of course you can't completely stop your
user doing something silly with their password, like pinning it up on their
notice board.
Setting up the server to do this this is probably less effort than getting a digital certificate, installing SSL, and so on, though it doesn't have as many security features. Inparticular you can't use it for transmitting passwords in the first place, thought PGP encrypted e-mails are an alternative. I've implemented it as a Perl CGI Script. Jamie Jaworski suggests using ASP in an article on CNET Builder.com.
| Limitations |
- An eavesdropper can still read the message being sent to the server - it's not encrypted.
- If a valid request to set the message is intercepted, the eavesdropper can re-send this (still valid) request as long as the time stamp is current.
- About a hundered more that I haven't thought of!
| Bugs and Updates |
1 May 2000 - I've changed this page, so it now uses just one form, and works insecurely with a non-JS browser.
8 Mar 2000 - Trevor Turton has fixed this page for use with Netscape.
 |
© 1998 - 2002 Paul Johnston, distributed under the BSD License Updated: 15 Dec 2002