Date: Mon, 27 Jan 2014 19:53:19 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Opinions sought on whether a specific side-channel leakage
 is ok.

On 27 January 2014 19:19, Marsh Ray <maray@...rosoft.com> wrote:

> From: Krisztián Pintér [mailto:pinterkr@...il.com]
> >
> > Peter Maxwell (at Monday, January 27, 2014, 4:20:55 PM):
> > > Without exposing too much of my intended design, I'd like to garner
> > > some opinion if that is possible.
> >
> > you are not going to file a patent, are you?
>
> For the record, similar ideas have been floated before.
>

​Do you have​ any references I could follow up on?  (I'd a feeling this
sort of thing would have at least been suggested before and would be good
to see what the end result was)
​​


>
> > > So, lets say we can associate a given password with a scalar password
> > > complexity measure in the interval [0,1] with an as yet to be defined
> > > distribution.
> >
> > here is my objection, above the obvious leak issue. calculating password
> strength is difficult. it will be a damn complex
> > algorithm, supported by tables, many equations and a sizeable dictionary.
>
> What is the entropy of 'Pa$$word1'?


>
Or a password for which the hash has been exposed in a data breach and
> possibly cracked?
>

To give a better idea of where I'm hoping to go with this: ideally, I'm
wanting to create a model with a small number of parameters that can be
fitted against existing password datasets (and have a very vague concept of
how it might be done from something I'd worked on last year).  The type of
dataset I had in mind was either a massive corpus of passwords that have
been found in the wild, with best-guess associated relative frequency data,
or, looking at the sequence of passwords tried by common password crackers
(so we're using the order to replace the frequency).

So the entropy of a specific password is arguably not important but rather
the relative commonality of use in the wild or how early in a testing
sequence a password cracker would test that candidate password.  Neither of
these should change particularly quickly because in general peoples'
choices of passwords don't move that fast - at least it hasn't
historically, hence the PHC - and password crackers try commonly used
passwords first (and there would be no advantage to deviate from that).
 It's a slightly hand-wavy argument but if we can at least test the former
if needs be, e.g. whether patterns of password choice have changed much in
the past 10 years.




>
> 'Complexity' might be something that an individual site could define on
> it's own. But making a standard definition of 'strength' or 'password
> entropy' seems basically impossible.
>

As Krisztián pointed out, standardization and making it small & efficient
is going to be paramount for smaller devices or certain environments;
granted, it's not going to be possible to do this in a particularly
accurate sense but if it can be done well enough, it should be sufficient.
 However, for larger systems or anybody who doesn't like following
standards, I suppose the model could be swapped-out for something custom or
indeed an absolutely massive table lookup.

​In end though, all the design really needs its an approximate measure of
password complexity -- the algorithm deliberately obfuscates the precise
measure anyway as a security precaution.​

Content of type "text/html" skipped

Powered by blists - more mailing lists