[j-nsp] Forced password resets?

[Saku Ytti]

Hey Julien.

Call me tinfoil kook, but I'm guessing same, DB got pwned or they have
reason to suspect it probably got owned, and wanted way to fix the
problem in due time.

Anyone up for some IETF fun? I think this PW problem can be mostly
solved by an standard API. I imagine that you have some credentials
wallet which supports the API, browser which supports the API and HTTP
server which supports the API. You have some way to locally lock down
and open the wallet, which is out-of-scope for the standard.
Now when you register to new site, your browser asks site about
authentication policy (what information is needed, what that
information can look like) it then asks wallet to provide such
information for set of hosts or URLs, and then browser offers this
information to the server.
It can do this every time you login, recycle the password every time,
or you can explicitly ask wallet to cycle all credentials at will.
Further server can provide subscription URL for security breaches,
which wallet can subscribe to, and change credentials as asked by
server. This way you don't know your authentication details, unless
you specifically ask the wallet, and it can be changed arbitrarily
often, can be arbitrarily complex, can include HOTP/TOTP and you don't
even have to know if it does or no does not.
Further you'd obviously get libraries for all common languages, so any
software you need authentication for, you can just use the API,
instead of NIHing some password prompt.

Nothing in this is novel, complex or even unimplemented, it's just
there isn't any standard for it.


And indeed periodic PW cycling by humans is bad, we just work around
easy to remember cycling strategy. Another dubious practice is having
specific set of  rules what is valid password, I tried to test for
example ESX vmcenter rules:

~ ❱ pwgen -s 8 2000|ruby -nae '$F.each{|pw|p (pw.gsub(/[^\d]+/,
"").size > 1 && pw.scan(/((.)\2*)/).map(&:first).any?{
    |e|e.size > 1})}'|grep true|wc -l
114
~ ❱ pwgen -s 8 2000|ruby -nae '$F.each{|pw|p (pw.gsub(/[^\d]+/,
"").size > 1 && pw.scan(/((.)\2*)/).map(&:first).any?{
    |e|e.size > 1})}'|grep true|wc -l
97
~ ❱ pwgen -s 8 2000|ruby -nae '$F.each{|pw|p (pw.gsub(/[^\d]+/,
"").size > 1 && pw.scan(/((.)\2*)/).map(&:first).any?{
    |e|e.size > 1})}'|grep true|wc -l
105
~ ❱ pwgen -s 8 2000|ruby -nae '$F.each{|pw|p (pw.gsub(/[^\d]+/,
"").size > 1 && pw.scan(/((.)\2*)/).map(&:first).any?{
    |e|e.size > 1})}'|grep true|wc -l
112

94.3 to 95.1 percent of the entropy is gone, due to random password
becoming invalid due to the policy. Quite the leg up for brute-forcer
beign able to ignore 95% of the problem.


On 19 April 2018 at 10:54, Julien Goodwin <jgoodwin at studio442.com.au> wrote:
> "To help ensure your trust and security on www.juniper.net, we are
> asking all our users to change their passwords every 180 days"
>
> This is considered to not be good practice[1], and as this is new, makes
> me wonder whether something has happened that Juniper don't want to
> admit to yet.
>
> A general requirement that accounts will be deactivated if they aren't
> used at least every six months is fairly understandable, but forcing a
> password change with it isn't.
>
> 1: Random point:
> https://www.ncsc.gov.uk/articles/problems-forcing-regular-password-expiry
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti