full-disclosure - [Re:] Interesting but vulnerable scheme for tokenless auth

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]

Message-ID: <20060426200639.1b1507a04a440dbbe6ab6eabc5c58a9e.97b0daf42f.wbe@email.secureserver.net>
Date: Thu Apr 27 07:58:04 2006
From: info at delsec.net (Chris)
Subject: [Re:] Interesting but vulnerable scheme for
	tokenless auth

Glenn,

There are a few parts of this I am confused on.

>In the cert is a private key. If the system were required to contact a 
>"backend" server first, passing it perhaps a cipher containing its
>serial number encrypted with its private key and its identity, the 

When you say pass a 'cipher' do you mean pass a message? And if you mean
pass a message then a  public/private crypto system would encrypt this
message using the backend servers public key, not its own private key.
Or perhaps I have misread your posting.

>server could send back a (hopefully unique to that cert) decryption key 
>that would decrypt the private key, allowing its use; the code at the PC 
>would need to erase the cleartext private key when done. The server 

Sending of any keys over the air like this is dangerous, thats what
makes public/private crypto systems good. The only drawback is you need
a good PKI to support those users and be the CA. The CA is the only
authority the system should 'trust' when it comes to certificate
validation and revocation. Which means a second 'backend' server may
not fit well into this picture. 

>could check the serial number matched the "identity" (it would have the 
>public key) to prevent a simple search of the server for these 
>encrypting keys.

I am not sure I understand this last part, please elaborate.

----------------------------------------
Chris 
Key ID: 7E8DE44E 
info@...sec.net
----------------------------------------