bugtraq - RE: Clear text password exposure in Datakey's tokens and smartcards

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ONEIKGNHAKIHOCLLDLNGGELJCAAA.israel.torres@ssplitronic.com>
Date: Thu, 5 Aug 2004 18:29:26 -0700
From: "Israel Torres" <israel.torres@...litronic.com>
To: "Kevin Sheldrake" <kev@...ctriccat.co.uk>,
   "Toomas Soome" <Toomas.Soome@...rolink.ee>, <lionel.ferette@...net.be>
Cc: <vuln@...view.com>, <full-disclosure@...ts.netsys.com>,
   <bugtraq@...URITYFOCUS.COM>, <israel.torres@...litronic.com>
Subject: RE: Clear text password exposure in Datakey's tokens and smartcards

Simply by exposing "another" vulnerability in a "secure" system allows judgement to be made on what type of hardware is necessary for the "secure system" (i.e. will this system serve as a public kiosk, or will this system be at the user's bidding?). Vulnerabilities should be kept to a minimum and narrow the choice of attack vectors an attacker may choose from when attempting to compromise a target system. Once a system is compromised and rooted there is little that can prevent the attacker from collecting what they are searching for (be it pins, passwords, source code, etc) before they vanish into the darkness. 

Israel Torres

-----Original Message-----
From: Kevin Sheldrake [mailto:kev@...ctriccat.co.uk]
Sent: Thursday, August 05, 2004 3:39 AM
To: Toomas Soome; lionel.ferette@...net.be
Cc: vuln@...view.com; full-disclosure@...ts.netsys.com;
bugtraq@...urityfocus.com
Subject: Re: [Full-Disclosure] Clear text password exposure in Datakey's
tokens and smartcards

Surely if the user is entering a passphrase then the same problem exists -  
that of effectively eavesdropping that communication from the keyboard?

Ignoring the initial expense for a moment, wouldn't it have made a lot of  
sense to include the keypad actually on the cards?  Obviously, card  
readers would need to be contructed such that the keypad part of the card  
would be exposed during use.  The keypad security could then rely on the  
tamper resistant properties of the rest of the card.

 From a costs perspective, I would guess that the actual per-card cost  
increase would be minimal if hundreds of millions of these cards were  
produced.

Kev

> Lionel Ferette wrote:
>
>> Note that this is true for almost all card readers on the market, not  
>> only for Datakey's. Having worked for companies using crypto smart  
>> cards, I have conducted a few risk analysis about that. The conclusion  
>> has always been that if the PIN must be entered from a PC, and the  
>> attacker has means to install software on the system (through directed  
>> viruses, social engineering, etc), the game's over.
>>  The only solution against that problem is to have the PIN entered  
>> using a keypad on the reader. Only then does the cost of an attack  
>> raise significantly. But that is opening another can of worms, because  
>> there is (was?) no standard for card readers with attached pin pad (at  
>> the time, PC/SCv2 wasn't finalised - is it?).
>>
>
> at least some cards are supporting des passphrases to implement secured  
> communication channels but I suppose this feature is not that widely in  
> use....  how many card owners are prepared to remember both PIN codes  
> and passphrases...
>
> toomas
>
>

-- 
Kevin Sheldrake MEng MIEE CEng CISSP
Electric Cat (Bournemouth) Ltd

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html