Poor man's authentication algorithm?

Question

Brainstorming request

I need an idea for an authentication algorithm with some unusual requirements.

The algorithm would be used to verify that the sender of a message is legitimate.

Restrictions:

1. The "transport layer" is e-mail
2. the sender ('Alice') is a human being
3. Alice only has access to a web browser and internet access (including a webmail account) as her tools; therefore she can't do very complicated calculations
4. The receiver ('Bob') is a computer with no direct access from the internet.
5. Bob has an email account that it checks periodically.
6. Bob can send email.
7. No sending info to a 3rd party: Alice and Bob can't send any out-of-band info. Reading some publicly available info (such as the time from a time server) is ok.

Assumptions:

• Alice can access some information locally: maybe she carries a notebook, or we could even assume her web mail account is hack-proof, therefore sensitive information can be stored there.
• Alice and Bob can exchange sensitive information directly at a time prior to the authentication (private keys?)

Non-goals:

• encoding of the actual payload of the message is not necessary.
• speed/latency are not (big) issues

Some ideas to get you started:

1. Plain old hard-coded password.
   Problems:

   • brute force attack (not likely)
   • eavesdroping possible if the communication is done in clear text, then replay attacks possible

2. Simple algorithm based on current date/time
   Example: Alice adds the current date, hour and minute and sends the result as the auth token, which Bob can verify. Let's assume that read-only access to a time server does not violate rule #7 (no 3rd party).
   Problems:

   • security through obscurity: the algorithm is somewhat safe only because it is not publicly available (well, it is now... oops!)

3. Some sort of challenge-response mechanism - Alice sends a request for authentication, Bob replies with a challenge, Alice sends the expected response and the actual payload.
   What are the details of the mechanism? I don't know :)

What can you think of? I'm hoping to see some creative answers ;-)

Edit:

Maybe an example would make rule #3 clearer: let's assume that Alice is using a proprietary closed-source device <cough> iPhone <cough> to access the Internet, or she is standing in front of a public internet kiosk.

Answer 1

Am I missing something obvious in suggesting a simple public/private key and signing the email?

Firefox has at least one extension to allow GPG in webmail.

Answer 2

Two options I can think of:

• Issue a card with one-time passwords (communication before the fact, notebook)
• Electronic device that produces pincodes (avoids replay-attacks)

Answer 3

If Alice can run code on her machine (for example by using JavaScript that is found on some public site, like: http://www.functions-online.com/en/sha1.html), she can receive the challenge, hash it together with the password, and send it back.

Answer 4

If you're not going to use PKI, which is far and away the best solution, try using a challenge-response system like CRAM-MD5 (although I'd suggest a different digest algorithm).

Your constraints make the implementation of a secure cryptographic system almost infeasible. Is there nothing you can do to change the transport?

Answer 5

Here's another suggestion:

• Start with the Diffie-Hellman key exchange, resulting in a shared private key, known only to presumably-Alice and Bob.
• Have a pre-defined password known only by Alice and Bob.
• Have Alice encrypt the password using the shared key and send it to Bob
• Now Bob can see that presumably-Alice really is Alice.

Problems:

• Diffie-Hellman is not safe using small numbers.
• What would be a simple symmetric encryption algorithm (for encrypting the password)?

Answer 6

There are several methods I can think of:

Install a https encrypted service similar to:

http://webnet77.com/cgi-bin/helpers/blowfish.pl

or

http://cybermachine.awardspace.com/encryption.php/

Or you could issue one-time passwords in combination with a XOR encryption

Or you can write a simple Java App (if Java can be executed in the machine) that can be loaded via www and provides public key encryption.

Answer 7

Consider to create a web page which contains the algorithm as JavaScript, possibly as a download (so she can download it once and carry it along on an USB drive).

The idea is that she opens the page, checks the source code (all JavaScript must be inline) and then enters her password in a text field on the page. The JavaScript will translate this into a code as she types (so no network traffic while she does this; if there is, there might be a keylogger running in the background).

After she has the code, she can copy it somewhere.

The JavaScript can use the current time as a seed. Slice the current time into five minute intervals. Most of the time, using the current time will be enough to decode the password and if you're close to the start of the five minute interval, try with the previous one.

See this site for an example: https://www.pwdhash.com/

Answer 8

Elaborating on lassevks answer:

In my company we use SecurID tokens from RSA for remote authentication.

It gives you a 6 digit number that changes every 60 seconds as an authentication token, supposedly your token generator and the server are the only ones in the universe which know the token that is valid right now.

As a low tech alternative, a set of n (10, 20, 100 - whatever is reasonable in your specific case) one time authentication codes can be given to Alice. I would ask her for a specific code (e.g. number 42 in the list). After using this code, it becomes invalid for further use.

Edit: See lacop's answer for a good implementation of the low tech solution.

Answer 9

A simple way to protect data in transit without exchanging passwords is the three-way-XOR:

1. Alice creates a few bytes using her own key.
2. She XORs the data with these bytes to make them unreadable.
3. Alice sends the encrypted data to Bob
4. Bob creates a few bytes using his own key.
5. He XORs the data with these bytes.
6. Bob send the double-encrypted data back to Alice
7. Alice applies her XOR pattern once more. Now, the data is only encoded with Bob's pattern
8. Alice sends the data back to Bob
9. Bob can now decode the data with his own pattern

Answer 10

Hmm... would this count as a thrid party?

Set up a brother of Bob - Charlie, who is accessible from the internet via HTTPS. To send a message to Bob Alice would first have to log on to Charlie (via plain old password) and then Charlie would give her a one-use token. Then she sends her email along with the token to Bob.

Answer 11

In addition to Treb's answer, you can use one-time passwords you can print instead of SecurID. See "Perfect Paper Passwords" for details.

Answer 12

My idea of a human-friendly low-tech challenge-response mechanism:

1. Bob changes the challenge every time he receives a valid message (for example he makes a salted hash of the current time)
2. every invalid message sent to Bob makes him reply with the current challenge, so Alice can query him by sending an empty mail
3. once Alice knows the challenge, she goes to https://www.pwdhash.com/
   • in "Site Address" she enters the current challenge
   • in "Site Password" she enters her personal password (which is known to Bob)
   • PwdHash generates a "Hashed Password"
4. Alice writes a message to Bob, using the hash just created as the subject
5. Bob receives the message, hashes the current challenge and Alice's password according to the PwdHash algorithm, and sees if his result matches the message subject
6. if it does, Bob accepts the message and and sends out a confirmation containing the new challenge (essentially this is step 1)

Advantages:

• cheap & simple, may even run on reasonably modern mobile devices
• human friendly (no math, easy to remember, prerequisites easily available on the net)
• no replay attack possible
• no clear text passwords over the wire
• does not run out of passwords (like one-time pads do)
• no inherent time limits (like RSA tokens have)
• the PwdHash web site can be saved on disk and called locally, no third party dependency here

Disadvantages:

• Bob and Alice must pre-share a key (Alice's password), therefore Alice cannot change her password off-site
• compromising Alice's password is the easiest attack vector (but that's the case with almost all password protected systems)

Note that PwdHash is an open hashing algorithm, Bob can easily implement it. The PwdHash web site works without post-backs, everything is client side JavaScript only, no traces left behind.

Answer 13

The most simple solution is to make Bob periodically send mails to Alice's mail account. When she needs something from Bob, she has to reply using one of these mails. Bob can put some check tokens into the mail (mail ID, or a string which must be repeated in the subject or body of the mail).

Just like many of the email verification schemes work.

Drawback: this only proves that the attacker has access to Alice's mail account, not that it is in fact Alice herself. To solve this, you could tell Alice a password and use the "JavaScript HTML page" trick so she can encode the key from Bob using her password.

This would prove that she has access to her mail account and that she knows the password.

Answer 14

I am currently writing up a patent application for an authentication method that appears to meet all of your posed constraints with none of the weaknesses identified in previously posted solutions. However I am unsure about how to commercialize my patent and don't want to fall into the trap of having a patent without a nmarket. Please let me know if, you know of a market that would justify the costs of patenting such an algorithm.