linux-kernel - Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

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: <200611181117.54242.david-b@pacbell.net>
Date:	Sat, 18 Nov 2006 11:17:53 -0800
From:	David Brownell <david-b@...bell.net>
To:	Anderson Briglia <anderson.briglia@...t.org.br>
Cc:	"Linux-omap-open-source@...ux.omap.com" 
	<linux-omap-open-source@...ux.omap.com>,
	linux-kernel@...r.kernel.org,
	Pierre Ossman <drzeus-list@...eus.cx>,
	Russell King <rmk+lkml@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	"Aguiar Carlos (EXT-INdT/Manaus)" <carlos.aguiar@...t.org.br>,
	"Biris Ilias (EXT-INdT/Manaus)" <Ilias.Biris@...t.org.br>
Subject: Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

On Friday 17 November 2006 4:58 am, Anderson Briglia wrote:

> - Password caching: when inserting a locked card, the driver should try
>    to unlock it with the currently stored password (if any), and if it
>    fails, revoke the key containing it and fallback to the normal "no
>    password present" situation.

Is there some reason why the key isn't associated with the MMC/SD card
identifier(s)?  It should be practical to swap several cards in/out
without the kernel _needing_ to discard their keys.  What you're saying
is that you'll cache only one key at a time, and that it won't have
anything associating it with a particular card.  That's not at all how
the key retention service is designed to work...

> - Some cards have an incorrect behaviour (hardware bug?) regarding
>    password acceptance: if an affected card has password <pwd>, it
>    accepts <pwd><xxx> as the correct password too, where <xxx> is any
>    sequence of characters, of any length. In other words, on these cards
>    only the first <password length> bytes need to match the correct
>    password.

I thought the MMC vendors expected to see the actual user-typed
password get SHA1-hashed into a value which would take up the whole
buffer?  In general that's a good idea, since it promotes use of
longer passphrases (more information) over short ones (easy2crack).

Plus, such hashing would prevent this issue ... if vendor tests are
done with hashed passphrases, that would explain why this class of
hardware issue got past design validation.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/