Designing an Authentication System

I read through housing.usc.edu/htp/dialogue.htm. It’s very interesting. If you haven’t read it already, I recommend that you do.

What follows are my comments and ideas, just things that popped into my head while reading:

Why can’t Charon just keep granting new tickets without asking for a password again?

A ticket is not required to maintain the session.

Malicious user could modify kinit to brute-force the password that was used to encrypt the ticket-granting ticket.

Network address can be spoofed with some network adapters.

With lifespan and timestamp, the ticket still can be copied and used on a spoofed workstation – but only for a shorter amount of time.

Hopefully not enough time for a workstation to brute-force the ticket’s password, thus decrypting it. Actually, even if the ticket has expired, decrypting the ticket would reveal the user’s password, assuming the system can tell when the ticket has been properly decrypted.

If not (any password returns seemingly valid output), then this is safe.

Workstation and Charon need to share a secret (encrypted).

session key + ticket, encypted with user’s password

Get session key by brute-forcing ticket, which is encrypted only by user password. If I have my own copy of the file, there’s no limit to the amount of computing power I could apply to cracking it.

acceptible -> acceptable

mutual authentication

“yields the correct server response message”

Have to make rogue server send the correct response message (requires session key — brute-forced from ticket)

Rogue server can take over real server between authentication and sending the document.

Document is not encrypted. Where is the data in the ticket? There is none. Data is sent cleartext.

“cannot generate the correct response because it cannot decrypt the ticket and get the session key.” Decrypt ticket with brute-force technique.

“If an attacker tries to snatch an authenticator and reuse it, even during the five-minute acceptance window, the replay cache will be able to determine that the authenticator has already been presented to the server.”

What if the attacker gets its authenticator to the server before the real server? Network jamming and faster computers/network devices could achieve this.

3 Responses to “Designing an Authentication System”

  1. hey this is kindof a random comment.. but…
    i just googled my old cybiko name “gareththegenius” and found this:
    http://www.intelliot.com/blog/archives/2002/08/
    i dont.. really remember who you are…though i would be curious to talk again.
    hope to hear from you some day!
    -gareth walters

  2. oh s— wait i know who you are O.O
    it .. all just came back to me.
    well um.. hi.

  3. holy s— i know im posting a bunch of random comments.. >

Leave a Reply