full-disclosure - (no subject)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Mon Dec 12 18:18:41 2005
From: jsmith1001 at post.com (John Smith)
Subject: (no subject)

>Firstly, the user ID isn't used anywhere, although its captured.

  The KPID is used to determine the unique algorithm used for time-delay,
and the static control algorithm used to create the dynamic encryption
for the unit's auth sequence, (the two hashes created using date/time
sequence and dynamic algorithm based off of control algorithm).  I might
not have explained that very well - sorry. One consideration would be the
large amount of different algorithms to keep track of, and whether a
dynamically generated algorithm can be trusted to have invariably similar
characteristics, (ie strength, any collisions).

>Second, this is still subject to a mitm attack.

 Well, I know that the MITM attack would still be possible with the
authenticated session, as the host is compromised, but I thought the
question was how to keep the authentication itself private, as using a
compromised system means everything is available anyway. Perhaps a kind
of keep-alive using the time-delay could help prevent excessively easy
interception of the session...

>Thirdly, any message or session data is not protected as coming from the
same site to/from user, compromised workstation or keypad. Indeed, a
compromised machine may simply 'route' an attacker's data to appear to
originate from the machine that commenced the session.

Now, the session could definitely be stolen, but again, I thought we were
assuming any session was going to be compromised already. Maybe I missed
the point. If we have to protect more then the authentication scheme,
from what little I know, there would have to be NO involvement with the
compromised machine, or users who can decrypt things themselves..hehehe -
decoder ring to check your email... :) Even hardware interrupts could be
intercepted and analysed, I believe though I'm not positive, if you,
say, decided to setup a method of direct communication between the USB
peripheral and the user-interfaces, (which would be cool, anyway).

Well, that was my thought. I'm no engineer, so it was more of a stab in
the dark, but thanks for your reply :) I think the time-delay thing and
the control algorithm dynamically generating unique algorithms during
encryption could really be expanded on. I haven't seen much along those
lines, personally. Perhaps its because of the overhead.

-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051212/9fc55c98/attachment.html