[lug] Application Password Security

[George Sexton]

On 6/20/2016 6:29 PM, Bear Giles wrote:
> That's from 2010. There are a few big differences:

I long ago gave up on trying to manage passwords. I have an app for my 
desktop and phone called Ascendo DataVault. When I signup for a new 
site, the password is randomly generated and goes in there. I really 
only try to remember a few passwords.

>
> 1. We have OAUTH. Pretty much all non-commercial sites should just 
> deter to Facebook, Google, and perhaps one or two other sites. Not 
> Facebook alone - not everyone wants Every. Single. Thing. they do 
> online tracked. Do that and a lot of password headaches go away.

We actually do OAuth for Twitter, Facebook, and EventBrite APIs so we 
understand the techniques pretty well. A typical use-case for our 
application is a church, school, or government entity signs up for our 
service. They then create accounts and assign permissions. OAuth to 
Facebook isn't a great fit for that.

We do support LDAP/AD authentication, but few customers take advantage 
of it for two reasons:

1) They have to expose an LDAP connection to us, which makes them nervous.

2) For LDAP authentication, you basically try to bind to the tree with 
the user's plaintext credentials. If I were a major government entity, 
the thought that a vendor could snoop my AD passwords would be a little 
unsettling. I saw that MS has an OAuth connector for Active Directory, 
but it looked pretty poorly documented.

>
> 2. We have MFA for sites that want higher security. There's a standard 
> protocol implemented by Google Authenticator and other phone apps and 
> hardware dongles. Any site that needs real security should make this 
> an option. It's not as important that the passwords themselves be rock 
> solid.
>
> 3. The banks have demonstrated some other MFA approaches. For instance 
> you have to respond to an SMS message to a registered phone number. 
> Once you've done this you have the option to "remember this computer" 
> and the bank will give you a longer-lived cookie but you always have 
> the option of disabling it and requiring the message.  (There are also 
> things like asking the user if they recognize an image or phrase - 
> that's a good way to do mutual authentication.)

We do support sending texts from our app, so I've thought of having an 
option for two-factor authentication.

>
> Put them together and the need to change passwords is reduced since 
> it's no longer the only factor.

My bigger concern is that my credentials database becomes a stepping 
stone into someone else's system. The most common "bad-guy" thing we've 
seen by people accessing our service is SEO spam for pharma.

>
> On the other hand some groups mandate password strength and validity 
> periods. E.g., I think if any part of your organization follows 
> PCI-DSS (for credit card info) then everyone has to follow those 
> rules. Security is only as strong as the weakest link and all that.
>
> On Mon, Jun 20, 2016 at 5:53 PM, Rob Nagler <nagler at bivio.biz 
> <mailto:nagler at bivio.biz>> wrote:
>
>     FWIW, here's what Schneier has to say about password changing:
>
>     https://www.schneier.com/blog/archives/2010/11/changing_passwo.html
>
>     Rob
>
>
>     _______________________________________________
>     Web Page: http://lug.boulder.co.us
>     Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>     Join us on IRC: irc.hackingsociety.org
>     <http://irc.hackingsociety.org> port=6667 channel=#hackingsociety
>
>
>
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety

-- 
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20160621/9550d3ee/attachment.html>