NYCPHP Meetup

[Federico Ulfo]

>
> The notion of "I don't have FB, therefore nobody should force FB auth"


Oauth should be an extra option not the only option!!!

Most people do use Social Networks but there's a small minority that
doesn't use or use them in a different way context, for example I use
Google+ only with my work email, could be unfortunate to register at the
bank with it because one day I may change job... I also have a joint
Facebook account, my wife and I share the same account and I'm sure that
other people found other original way to use social in an unconventional
way. Also don't forget that there are Tumblr, Pinterest ... and in other
countries other social networks, Sina Weibo etc.

Oauth is a safe solution that makes our life one click away to be easier,
but the authentication through password will stick around still for a
little bit therefore restriction and security will have to stay high as
well so expect website that ask a password that contains absurd klingon
characters in it.






On Tue, Jun 10, 2014 at 9:26 AM, Jerry B. Altzman <jbaltz at altzman.com>
wrote:

> on 6/9/2014 7:04 PM David Krings said the following:
>
>> On 6/9/2014 10:44 AM, Jerry B. Altzman wrote:
>>
>>> on 6/7/2014 10:38 AM Gary Mort said the following:
>>>
>>>> A plea to anyone setting up a website where you will have users log on.
>>>> Make
>>>> your default password rule something simple, like any 4 charectors.  A
>>>>
>>>
>>  password complexity system should allow for multiple tiers of rules with
>>>> configurable default rule that is set, by default :-), to something
>>>> simple.
>>>> Tune those tiers and defaults based on your website need, not by blindly
>>>> implementing the preachings of the high priests of security.
>>>>
>>> That I agree with. Don't put Fort Knox security on a site that contains
>> nothing secret. Then again, no matter how good security is, if it is really
>> delicate info don't put it on the web at all.
>>
> It's all about your risk model.
>
>
>  http://bit.ly/1xxLQXJ (Link is SFW.)
>>> Better yet: don't make users create accounts if they don't have to. Let
>>> them
>>> log in with FB, LinkedIn, Twitter, or Google accounts instead. The
>>> chances are
>>> the user already HAS one of those.
>>>
>>
>> I wouldn't count on people having this. Some places ask me to sign in
>> with my FB account. I don't have one and the idea of expecting me to have
>> one is rather obnoxious. I also doubt if it is wise to outsource security
>> to a third party.
>>
>
> Sorry, I respectfully disagree. Of the several I mentioned, you claimed to
> only have one. You can offer the 'create your own account', but users
> should be encouraged to use some other account and use something like OAuth
> to provide user authentication.
>
> The notion of "I don't have FB, therefore nobody should force FB auth" is
> equivalent to saying "we must absolutely positively backwards support IE6".
> This is 2014, sorry, if you don't want any social media accounts, that's
> your prerogative, but the vast majority of everyone else does.
>
>
>  And offer more options for the second factor. For example, I do not have
>> a smartphone (yes, saves a lot of money every month). So unless you can
>> figure out how to send an SMS to my landline forget it. In 2014 it should
>> be possible to dial my phone and use voice recognition to confirm a pass
>> phrase.
>>
> In fact, Sprint will do text-to-voice if it detects a voiceline (or at
> least it used to). But once again, we shouldn't aim towards supporting IE6
> forever. We're also not optimizing the user experience for those using
> lynx...
> Remember that you are not the world.
>
>
>  accounts most likely only need complex passwords[based on potential damage
>>>> of a compromised account...if a site manager can give out refunds and
>>>> credits for an e-commerce site, obviously you want to add extra
>>>> security!]
>>>>
>>> Yes, for these things, you almost certainly want a second layer of
>>> authentication atop the ones above. For these, little crypto keyfobs are
>>> great. If the potential financial loss is large, the client should not
>>> balk at
>>> the relatively small cost.
>>>
>>
>> I agree, but in best US fashion the industry miserably fails at agreeing
>> on a standard here. Then again, with any of these fobs you are
>> authenticating the fob, not the person holding the fob. For that you'd need
>> biometrics which is yet another can of worms.
>>
> Indeed: you are assuming that the user has both something-you-know and
> something-you-have. Biometrics isn't foolproof either, vis
> http://bbc.in/1oQshE4 (link is SFW).
>
>
>  More and more people just use "I forgot my password", and deal with it
>>> that
>>> way. Either you've exchanged the password for a security question, or
>>> just
>>> access to a user's email.
>>>
>> That's because passwords suck! As do password managers which end up being
>> the single point of failure (I do use them anyway). As mentioned above, it
>> is sad that after over 50 years of client/server computing there is nothing
>> better than and as accepted as user names and passwords.
>>
> User authentication is hard. Let's go shopping!
>
>  David
>>
>
> //jbaltz
>
> --
> jerry b. altzman | jbaltz at altzman.com | www.jbaltz.com | twitter:@lorvax
> thank you for contributing to the heat death of the universe.
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show-participation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20140610/627160a0/attachment.html>