[180234] in North American Network Operators' Group
Re: Password storage (was Re: gmail security is a joke)
daemon@ATHENA.MIT.EDU (shawn wilson)
Thu May 28 16:36:49 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <CAL9jLaYK3r6e6eShbz5vbaSzhyTNmX5OfHu7bFH+_XsyUJ8+dg@mail.gmail.com>
Date: Thu, 28 May 2015 16:36:45 -0400
From: shawn wilson <ag4ve.us@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On May 28, 2015 10:11 AM, "Christopher Morrow" <morrowc.lists@gmail.com>
wrote:
>
> On Thu, May 28, 2015 at 5:29 AM, Robert Kisteleki <robert@ripe.net> wrote:
> >
> >> Bcrypt or PBKDF2 with random salts per password is really what anyone
> >> storing passwords should be using today.
> >
One thing to remember is the hardware determines number of rounds. So while
my LUKS (PBKDF2) pass on my laptop or servers have a few 10k rounds, that
same pass on a Pi or so would only have 1k rounds (minimum rec).
>
> I get the feeling that, along with things like 'email address
> verification' in javascript form things, passwd storage and management
> is something done via a few (or a bunch of crappy home-grown) code
> bases.
Not generally passwords per se but session tokens and the like, sure
(almost as bad).
>
> Seems like 'find the common/most-used' ones and fix them would get
> some mileage? I don't imagine that 'dlink' (for example) is big on
> following rfc stuff for their web-interface programming? (well, at
> least for things like 'how should we store passwds?')
Heh, I started on a fuzzer that'd take a few strings and run them through
recipes (base 32/64, rot, xor 1 or 0, etc) and try to find human strings
along the way. If multiple strings match a recipe, you can generate your
own sessions.
