[colug-432] Hash and salt, where does the salt go ?

[R P Herrold]

On Mon, 6 Jan 2014, Tom Hanlon wrote:

> If Alice has a password after her cat, fluffy.
> 
> And we go to store that password we would hash it.
> 
> Before we hash it we add some salt ( now I am getting hungry for some
> salted hash)
> 
> So fluffy = > salt+fluffy =>hash => password file

The answer is: it depends if the end unit NEEDS to be able to 
locally solve the hash question, or if it can defer to a 
trusted unit in a protected location

If you wish the unit holding the password, within its four 
corners, to be able to receive a plaintext password, append 
the salt, and re-hash it for comparison, you need to have it 
in the salt locally:  see:
	man 3 crypt

basically:
	hashing method +
	salt +
	hash to match

which describes the datastructure

In the case of the compomised pin hashes at Target, the 
suggestion was made that the fulltext of the debit card number 
of (or a hash of that fulltext PLUS local fixed salt 
[hereinafter: LFS] of -- I have seen two ocnflicting press 
account versions) was used as a ** non-transferred ** 'salt' 
to generate a Message Authentication Code [MAC] to hand to a 
CC (and debit card) authorization Servicing Organization 
(either an Independent, or the issuing bank as the SO)

Since a sufficient pointer had to be transferred to permit 
acquisition of the fulltext of the debit card number has to be 
transferred anyway [and customarily is across a different data 
path than the PIN transfer], there is no good reason to carry 
it along in a datastructure along with the authenticating PIN 
as well.  In clearing pre-paid cards, we used a 20 digit 
account number on the mag stripe that was a pointer to permit 
us to look up the true account number on our back end.  
Without the dereferencing table [maintained in a very secure 
location], the details of the info on the stripes was meanless

I do not know that debit cards account numbers are similarly 
treated, but I would suspect so.  There is no reason not to 
carry more than the seemingly truncated 'last 4' on the card, 
because a debit transaction needs to communicate with the 
ultimate credit grantor to get a 'yea' or ' nope' anyway, and 
it can do a similar lookup

A cautious transmitter would probably also vary its LFS 
periodically -- daily, hourly, whatever -- to avoid 'replay 
attacks' with intercepted MACs

so the salt there for the LFS might look like:
	date +%Y%m%d%H

PLUS a local entropy string, random looking in form such as:
	[herrold at centos-6 ~]$ date | md5sum - | awk {'print $1'}
	0877d5052fd43570d1bc1979c407e4ea

concatenated together.  

so for card: 4567 8901 2345 6789
with the pin of: 1234
for hour: [herrold at centos-6 ~]$ date +%Y%m%d%H
	2014010617
plus that site random local entropy, would need to match:
	
[herrold at centos-6 ~]$ echo "4567 8901 2345 \
	6789123420140106170877d5052fd43570d1bc1979c407e4ea" | \
	tr -d ' ' | md5sum - | awk {'print $1'}
466e5a9ee2c7eaddf428c2f5f20b908c

The 'tr' is present because spaces are not used in the 
computation

[herrold at centos-6 ~]$ echo \
	"4567890123456789123420140106170877d5052fd43570d1bc1979c407e4ea" | \
	tr -d ' ' | md5sum - | awk {'print $1'}
466e5a9ee2c7eaddf428c2f5f20b908c

Note that here (unlike the passwd /shadow file example) we do 
NOT carry the salt elements [acct no, MAC stirring nonce, or 
local side entropy add-on] next to the hash to be matched, so 
the holder of just the hashes cannot get very far.  The Target 
people SEEM unconcerned about compromises, even though they 
used a nominally symmetric form of encryption [3DES] for the 
file

-- Russ herrold