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


Groups > sci.crypt > #32890

Re: storing passwords

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

Show all headers | View raw


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


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