Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Newsgroups | sci.crypt |
|---|---|
| Subject | Re: storing passwords |
| References | <op.x6gohjykwei6gd@phenom-pc> <gv2dnUB71cDc74DLnZ2dnUU78IednZ2d@giganews.com> |
| From | "David Eather" <eather@tpg.com.au> |
| Message-ID | <op.x6iphssewei6gd@phenom-pc> (permalink) |
| Date | 2015-10-15 08:45 +1000 |
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
Back to sci.crypt | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web