Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.crypt > #32835 > unrolled thread

storing passwords

Back to article view | Back to sci.crypt

Contents

  storing passwords "David Eather" <eather@tpg.com.au> - 2015-10-14 06:28 +1000
    Re: storing passwords Jakob Bohm <jb-usenet@wisemo.com> - 2015-10-13 23:06 +0200
      Re: storing passwords "David Eather" <eather@tpg.com.au> - 2015-10-15 08:45 +1000
    Re: storing passwords Paul Rubin <no.email@nospam.invalid> - 2015-10-13 14:22 -0700
      Re: storing passwords Jakob Bohm <jb-usenet@wisemo.com> - 2015-10-13 23:42 +0200
        Re: storing passwords Paul Rubin <no.email@nospam.invalid> - 2015-10-13 14:48 -0700
          Re: storing passwords Jakob Bohm <jb-usenet@wisemo.com> - 2015-10-14 00:09 +0200
            Re: storing passwords <william@wilbur.25thandClement.com> - 2015-10-16 18:08 -0700
              Re: storing passwords Jakob Bohm <jb-usenet@wisemo.com> - 2015-10-19 15:51 +0200
    Re: storing passwords "David Eather" <eather@tpg.com.au> - 2015-10-15 08:45 +1000
    Re: storing passwords Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-15 15:51 -0500

#32835 — storing passwords

I have a project where I would like to store a relatively large number of  
passwords in a relatively small space. I came up with this and just want  
some other eyes to spot the obvious flaw that I can't see.

(assuming the actual storage device is tamper proof and cannot be hacked -  
ok that one flaw but lets over look that)

I have a salt and a large secret password (hard-coded into the tamper  
proof design) such that the length of the salt and password makes  
inverting a hash function practically impossible. To that I append a short  
counter and the combined salt & long password & counter is hashed to give  
a user password.

(just re-reading that I don't need a salt I can just use a longer secret  
password)

If I have 2**n  - 1 passwords is it still impossible to guess or derive  
the missing password? (I think yes)

Other than such tamper proof hardware not existing and not being able to  
choose your own passwords is there some other flaw I have missed?

[toc] | [next] | [standalone]

#32837

On 13/10/2015 22:28, David Eather wrote:
> I have a project where I would like to store a relatively large number
> of passwords in a relatively small space. I came up with this and just
> want some other eyes to spot the obvious flaw that I can't see.
>
> (assuming the actual storage device is tamper proof and cannot be hacked
> - ok that one flaw but lets over look that)
>
> I have a salt and a large secret password (hard-coded into the tamper
> proof design) such that the length of the salt and password makes
> inverting a hash function practically impossible. To that I append a
> short counter and the combined salt & long password & counter is hashed
> to give a user password.
>
> (just re-reading that I don't need a salt I can just use a longer secret
> password)
>
> If I have 2**n  - 1 passwords is it still impossible to guess or derive
> the missing password? (I think yes)
>
> Other than such tamper proof hardware not existing and not being able to
> choose your own passwords is there some other flaw I have missed?

If someone develops a cryptanalytic attack against the chosen hashing
function, possibly taking advantage of the restricted way in which you
use it, they can take any (small or large) set of pairs of "user
password, user number") and compute a formula that gets from "user
number" to "user password" with or without bothering to find your
master key in the process.

This is why this is generally a *bad* way to build a random number
generator, even though some cheap manufacturers of actual tamper proof
security chips have done exactly what you suggest.

Another example of this is the small key generators made by companies
such as RSADSI ("RSA Tokens") which generally work that way to display
a new temporary password every time you log on while the server does
the same calculation to know which password is right at any give time.

Many of those became completely insecure once someone got hold of the
super-master-password used at the RSA factory to make the user master
passwords stored inside the tokens.

Put another way, having the security of everybody depend on a single
master secret is simply too high a risk.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[toc] | [prev] | [next] | [standalone]

#32890

On Wed, 14 Oct 2015 07:06:09 +1000, Jakob Bohm <jb-usenet@wisemo.com>  
wrote:

> On 13/10/2015 22:28, David Eather wrote:
>> I have a project where I would like to store a relatively large number
>> of passwords in a relatively small space. I came up with this and just
>> want some other eyes to spot the obvious flaw that I can't see.
>>
>> (assuming the actual storage device is tamper proof and cannot be hacked
>> - ok that one flaw but lets over look that)
>>
>> I have a salt and a large secret password (hard-coded into the tamper
>> proof design) such that the length of the salt and password makes
>> inverting a hash function practically impossible. To that I append a
>> short counter and the combined salt & long password & counter is hashed
>> to give a user password.
>>
>> (just re-reading that I don't need a salt I can just use a longer secret
>> password)
>>
>> If I have 2**n  - 1 passwords is it still impossible to guess or derive
>> the missing password? (I think yes)
>>
>> Other than such tamper proof hardware not existing and not being able to
>> choose your own passwords is there some other flaw I have missed?
>
> If someone develops a cryptanalytic attack against the chosen hashing
> function, possibly taking advantage of the restricted way in which you
> use it, they can take any (small or large) set of pairs of "user
> password, user number") and compute a formula that gets from "user
> number" to "user password" with or without bothering to find your
> master key in the process.
>
> This is why this is generally a *bad* way to build a random number
> generator, even though some cheap manufacturers of actual tamper proof
> security chips have done exactly what you suggest.
>
> Another example of this is the small key generators made by companies
> such as RSADSI ("RSA Tokens") which generally work that way to display
> a new temporary password every time you log on while the server does
> the same calculation to know which password is right at any give time.
>
> Many of those became completely insecure once someone got hold of the
> super-master-password used at the RSA factory to make the user master
> passwords stored inside the tokens.
>
> Put another way, having the security of everybody depend on a single
> master secret is simply too high a risk.
>
>
> Enjoy
>
> Jakob

Not a problem - everyone gets their own device and the hash function will  
be sha-2-256

[toc] | [prev] | [next] | [standalone]

#32839

"David Eather" <eather@tpg.com.au> writes:
> I have a salt and a large secret password (hard-coded into the tamper
> proof design) such that the length of the salt and password makes
> inverting a hash function practically impossible. To that I append a
> short counter and the combined salt & long password & counter is
> hashed to give a user password.

The details are usually a bit different but the above is basically a
standard scheme.  You'd have a large key K in the device, and the user
password can be something like HMAC(K, userid) truncated to the amount
of bits you want to give to the user.  You'd typically generate K itself
from some other master secret in the device, for more flexibility; add
more indirection or another counter so the user can change passwords,
etc.  The verification would be done in the module so when you check a
password, you just get a yes or no, you never get to see the hash.

> Other than such tamper proof hardware not existing and not being able
> to choose your own passwords is there some other flaw I have missed?

The tamper proof (or at least resistant) device is also standard, and
called a host security module (HSM).  The ones actually sold as HSM's
are expensive because they're used in industries that are fairly
insensitive to cost, but they are basically microprocessor boards in
tamper resistant enclosures.  You can do similar things with smart
cards, whose tamper resistance these days is quite good, thpugh they are
much slower than HSM's.  Of course you will have to make security and
design decisions around the possibilities of the cards or HSMs being
stolen, breaking, etc.

[toc] | [prev] | [next] | [standalone]

#32842

On 13/10/2015 23:22, Paul Rubin wrote:
> "David Eather" <eather@tpg.com.au> writes:
>> ...
> The tamper proof (or at least resistant) device is also standard, and
> called a host security module (HSM).  The ones actually sold as HSM's

I think HSM stands for Hardware Security Module, not Host (With the
possible exception of some brands that don't follow common nomenclature
in their product names).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[toc] | [prev] | [next] | [standalone]

#32843

Jakob Bohm <jb-usenet@wisemo.com> writes:
> I think HSM stands for Hardware Security Module, not Host 

I've seen it both ways.  Not sure which is more current.

[toc] | [prev] | [next] | [standalone]

#32846

On 13/10/2015 23:48, Paul Rubin wrote:
> Jakob Bohm <jb-usenet@wisemo.com> writes:
>> I think HSM stands for Hardware Security Module, not Host
>
> I've seen it both ways.  Not sure which is more current.
>

I have seen HSM products that were not placed within any specific host
computer.  The most common these days is a tamper proof "SSL
accelerator" HSM, which stores the secret key of a website certificate,
handles all incoming HTTPS and SPDY requests, then forwards the actual
request over a trusted Ethernet cable to the real web server.

These typically are installed as their own 1U box in a rack, and thus
are not a "Host Security Module" for any particular host.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[toc] | [prev] | [next] | [standalone]

#33015

Jakob Bohm <jb-usenet@wisemo.com> wrote:
> On 13/10/2015 23:48, Paul Rubin wrote:
>> Jakob Bohm <jb-usenet@wisemo.com> writes:
>>> I think HSM stands for Hardware Security Module, not Host
>>
>> I've seen it both ways.  Not sure which is more current.
>>
> 
> I have seen HSM products that were not placed within any specific host
> computer.  The most common these days is a tamper proof "SSL
> accelerator" HSM, which stores the secret key of a website certificate,
> handles all incoming HTTPS and SPDY requests, then forwards the actual
> request over a trusted Ethernet cable to the real web server.
> 
> These typically are installed as their own 1U box in a rack, and thus
> are not a "Host Security Module" for any particular host.
> 

They're not much of a hardware security module, either. Sometimes just LAMP
stacks (or equivalent or, worse, some homegrown code). In some ways that's
worse than managing things yourself, because such appliances aren't often
well maintained by the vendor in the long term, or even in the short term.

I always understood the module part to mean a device with very specific,
minimalist physical components and a very limited communications channel to
mitigate flaws in any firmware (i.e. anything with a network stack is not
sufficiently limited). In which case, it would follow as a practical matter
that it would be paired with a single host.

I bought several beta Yubikey NEO tokens. Alas, the firmware (Java Card
applet) contained a bug which allowed the PIN to be bypassed. That didn't
bother me so much--a smartcard without PIN protection is still much
preferable to the alternatives. I was just disappointed that the device
wasn't simpler.

At least they use a GPL'd Java Card applet, susceptible to independent code
review. And people have indeed submitted patches.

Presuming the Name Constraints extension to the X.509 PKI standard has
become useable, and there are root CAs that sell delegated CA rights for
subdomains, I'd chose that route over a 1U rack-mounted so-called HSM. The
price would presumably be similar. I'd generate and keep the secret key on a
cheap smartcard--the Yubikey should suffice. I'd periodically take it out of
the lockbox and generate new intermediate certificates for my servers. An
offline PC would work nearly as well.

It's basically what Google does. Although I think they're a global CA root
and so don't need to rely on the Name Constraints extension.

[toc] | [prev] | [next] | [standalone]

#33059

On 17/10/2015 03:08, william@wilbur.25thandClement.com wrote:
> Jakob Bohm <jb-usenet@wisemo.com> wrote:
>> On 13/10/2015 23:48, Paul Rubin wrote:
>>> Jakob Bohm <jb-usenet@wisemo.com> writes:
>>>> I think HSM stands for Hardware Security Module, not Host
>>>
>>> I've seen it both ways.  Not sure which is more current.
>>>
>>
>> I have seen HSM products that were not placed within any specific host
>> computer.  The most common these days is a tamper proof "SSL
>> accelerator" HSM, which stores the secret key of a website certificate,
>> handles all incoming HTTPS and SPDY requests, then forwards the actual
>> request over a trusted Ethernet cable to the real web server.
>>
>> These typically are installed as their own 1U box in a rack, and thus
>> are not a "Host Security Module" for any particular host.
>>
>
> They're not much of a hardware security module, either. Sometimes just LAMP
> stacks (or equivalent or, worse, some homegrown code). In some ways that's
> worse than managing things yourself, because such appliances aren't often
> well maintained by the vendor in the long term, or even in the short term.
>

If done right they are safer and simpler than a full web server with
lots of unvetted "server side" scripts etc.  Furthermore, to qualify as
proper HSM's they would still need to do all the other hard stuff:
Guaranteed key deletion if anyone tries to physically penetrate the
box, carefully vetted design etc.

Also, the better ones include an "inner" HSM which actually does just
the public key stuff, plus hardware-accelerated symmetric processing to
handle data at wire speed (think 3DES today and AES before CPUs had it).

> I always understood the module part to mean a device with very specific,
> minimalist physical components and a very limited communications channel to
> mitigate flaws in any firmware (i.e. anything with a network stack is not
> sufficiently limited). In which case, it would follow as a practical matter
> that it would be paired with a single host.

Some single-host HSMs (like the IBM ones) are highly complex beasts in
terms of interface and power.  Most single-host HSMs sit on a powerful
and flexible extension bus such as PCI (the bus, not the policy).

>
> I bought several beta Yubikey NEO tokens. Alas, the firmware (Java Card
> applet) contained a bug which allowed the PIN to be bypassed. That didn't
> bother me so much--a smartcard without PIN protection is still much
> preferable to the alternatives. I was just disappointed that the device
> wasn't simpler.
>

In my experience, Java Card was always a badly designed system, that
makes smart card programming harder, not easier.  And in ways that in
no way benefit security.  For example memory operations fail to
distinguish between ephemeral values that should not survive a card
power cycle and persistent values that must.  And then there are the 
broken integer types (more broken than in desktop java), randomly 
missing features etc.

> At least they use a GPL'd Java Card applet, susceptible to independent code
> review. And people have indeed submitted patches.
>

Now try vetting the much larger blob of Java interpreter on the chip
and think of the huge number of quarterly desktop java flaws that are
still getting fixed.

> Presuming the Name Constraints extension to the X.509 PKI standard has
> become useable, and there are root CAs that sell delegated CA rights for
> subdomains, I'd chose that route over a 1U rack-mounted so-called HSM. The
> price would presumably be similar. I'd generate and keep the secret key on a
> cheap smartcard--the Yubikey should suffice. I'd periodically take it out of
> the lockbox and generate new intermediate certificates for my servers. An
> offline PC would work nearly as well.
>

Unfortunately, it isn't there yet, and CAs that sell delegated CA
rights without extreme levels of vetting and auditing are more likely
than not to get themselves cancelled out of trust stores due to some
delegated CA heavily abusing those rights.

A more commonly accepted (and secure) method is to use a CA that allows
you to change your private key (by submitting a new CSR to a login-
protected web page), thus allowing you to change the server private key
more often than you pay for getting your identity (but not security
practices) vetted.


> It's basically what Google does. Although I think they're a global CA root
> and so don't need to rely on the Name Constraints extension.
>

No, they are not (yet).  Unlike Microsoft.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[toc] | [prev] | [next] | [standalone]

#32891

On Wed, 14 Oct 2015 06:28:21 +1000, David Eather <eather@tpg.com.au> wrote:

> I have a project where I would like to store a relatively large number  
> of passwords in a relatively small space. I came up with this and just  
> want some other eyes to spot the obvious flaw that I can't see.
>
> (assuming the actual storage device is tamper proof and cannot be hacked  
> - ok that one flaw but lets over look that)
>
> I have a salt and a large secret password (hard-coded into the tamper  
> proof design) such that the length of the salt and password makes  
> inverting a hash function practically impossible. To that I append a  
> short counter and the combined salt & long password & counter is hashed  
> to give a user password.
>
> (just re-reading that I don't need a salt I can just use a longer secret  
> password)
>
> If I have 2**n  - 1 passwords is it still impossible to guess or derive  
> the missing password? (I think yes)
>
> Other than such tamper proof hardware not existing and not being able to  
> choose your own passwords is there some other flaw I have missed?

Thanks everyone!

[toc] | [prev] | [next] | [standalone]

#32970

On 2015-10-13 20:28:21 +0000, David Eather said:

> (assuming the actual storage device is tamper proof and cannot be 
> hacked - ok that one flaw but lets over look that)

If you really make that assumption then you might as well store the 
passwords in plaintext. The fact that you do not wish to do so tells me 
that you are (correctly) concerned about the device being hacked. 
(Under certain definitions of "hacked".)


> I have a salt and a large secret password (hard-coded into the tamper 
> proof design) such that the length of the salt and password makes 
> inverting a hash function practically impossible. To that I append a 
> short counter and the combined salt & long password & counter is hashed 
> to give a user password.

As someone pointed out

K = "large secret password (hard-coded) ...
salt = per record random salt
counter = "a short counter"

As someone else pointed out,

 HMAC(K, salt||counter||password)

is the usual construction for this. "K" is sometimes called "pepper". 
And its operations are often placed on an HSM (which I've also heard of 
as both "Hardware" or "Host")


> (just re-reading that I don't need a salt I can just use a longer 
> secret password)

No. You still need the salt. Its job is so that if two people use the 
same password, you cannot identify the fact that they do by inspecting 
the hashes. I'm not sure what the counter is for, though.

> If I have 2**n  - 1 passwords is it still impossible to guess or derive 
> the missing password? (I think yes)

Is n the the size of K? I *think* you are ok as long as you do use a 
random and unique salt for each and use something like HMAC.

Cheers,

-j

[toc] | [prev] | [standalone]

Back to top | Article view | sci.crypt

csiph-web