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

Groups > comp.misc > #4667

Re: Neat implementation of the master password idea

Show all headers | View raw

Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
> Hallöchen!

> A coupld of weeks ago, the German c't magazin published an article
> about password management.  (Unfortunately, it is not one of the few
> that got translated into English
> <http://www.heise.de/ct/heft/2014-18-Ein-neues-Konzept-fuer-den-Umgang-mit-Passwoertern-2284364.html>.)
> The key point is the discussion of <http://masterpasswordapp.com/>.
> Yesterday, I switched my passwords to it, and I am very much in awe
> of the thing.  The principle is quite simple and not even new -- the
> Master Password App itself is around since 2011 -- but googling for
> it yields suprisingly few hits.

> While I don't want to say that this method superseds password vaults,
> it is certainly the better method for me.  Especially because I like
> lightweight solutions: Install the program, enter your master
> password, your name, and the service's name.  Nothing stored.  No
> files to be synced or to be backuped or to be lost.

If I'm understanding your description properly and if I'm understanding
the description on the website properly, this is vulernerable to an
"offline" dictionary attack, without ever having any access to any of
your data.

There are three inputs that get "hashed" together:

1) your full name (publicly known)
2) the site name (publicly known)
3) your "master password" (the secret)
4) site sequence number (will usually be zero, because most folks never
   change their password, but even so, will likely be a small value in any
   case) (trivial to "guess" or to just enumerate)

All someone has to do to try to determine your password for site X
(assuming they have knowledge you use site X [also publicly known in
most instances]) is run an offline dictionary attack against the four
items above (three of which do not vary during the run), and "test"
each password against the site.

If they happen to hit upon your master password (which totally depends
upon how strong you make it, most people won't make it very strong) by
finding an output that accesses the site, they now have everything
necessary to determine all your passwords for all your sites, without
running any more brute force attacks.

At least with a "vault" app, provided it generates truly randomized
password strings, the attacker has to manage to get ahold of a copy of
your vault before they can begin to run an offline attack.  With this
system, they need nothing more than the mere fact that you utilize it
and they can start running an offline attack against you.

And the only protection you have from the offline attack is that site X
impliments a three trys and you are locked feature.  If only one of
your sites does not impliment a lock when too many failed tries occurs
feature, it becomes even more trivial to bruteforce your master
password, because that site becomes the keystone to breaking your
master password.

Back to comp.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Neat implementation of the master password idea Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-09-02 19:08 +0200
  Re: Neat implementation of the master password idea Rich <rich@example.invalid> - 2014-09-02 20:52 +0000
    Re: Neat implementation of the master password idea Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-09-03 08:31 +0200

csiph-web