From garyamort at gmail.com Sat Jun 7 10:38:02 2014 From: garyamort at gmail.com (Gary Mort) Date: Sat, 07 Jun 2014 10:38:02 -0400 Subject: [nycphp-talk] Relax your password rules Message-ID: <539323CA.4020204@gmail.com> 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. This is not the security nightmare many so-called "experts" try to lead you to believe. In fact, it is just the opposite. If you require users to use long passwords with 'complexity' then it doesn't really matter how you choose to encode and store those passwords, you might as well be using cleartext storage. Most people will use the same password on every website they sign up for when forced to make them complex - so no matter how securely you hash that password, it's stored on dozens of other websites as well - so the account on your website is only as secure as the weakest security all those websites they have used it on is using. The problem is that since open source software tends to blindly follow the "experts", they all default to either 'mixed case with numbers' or 'mixed case with numbers and symbols'. A google account which is often used as a hub for other logons, access to e-mail for password resets, etc should use a long, difficult to remember, complex password. But your NYPHP e-mail list password - which can only be used to change your e-mail subscription options? You can't even post to the list with it. No reason to insist on 'complex' passwords. If you use password authentication for user accounts, then base your rules on your needs. Site owner/Super Admin/Developer accounts should require complex passwords and two factor authentication. Day to day site manager 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!] User accounts which can access sensitive user data[credit cards, payment methods, etc... though really you shouldn't allow read access to that data!] need complexity. User accounts which can do things like make payments using saved payment methods need complexity. User accounts which can only add items to a wishlist or cart, post forum messages, etc don't need complexity. YOU may not want someone to be able to post to a forum with your account - but that doesn't mean you have to force complexity on others - you can choose complexity voluntarily and let the users decide how complex/safe they wish their passwords to be. Every time I browse around to some interesting looking website where I have to "create an account" to access something I get increasingly upset at those sites trying to force their idea of security on an account that I don't care about. If I decide I want to actively use the site and am giving it sensitive information, I will change that password to something complex. If I never return to that site, then I don't care about the account. From jbaltz at altzman.com Mon Jun 9 10:44:06 2014 From: jbaltz at altzman.com (Jerry B. Altzman) Date: Mon, 09 Jun 2014 10:44:06 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <539323CA.4020204@gmail.com> References: <539323CA.4020204@gmail.com> Message-ID: <5395C836.6080100@altzman.com> 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. 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. > If you use password authentication for user accounts, then base your > rules on your needs. Site owner/Super Admin/Developer accounts should > require complex passwords and two factor authentication. Day to day > site manager 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. > Every time I browse around to some interesting looking website where I > have to "create an account" to access something I get increasingly > upset at those sites trying to force their idea of security on an > account that I don't care about. If I decide I want to actively use > the site and am giving it sensitive information, I will change that > password to something complex. If I never return to that site, then I > don't care about the account. 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. //jbaltz -- jerry b. altzman | jbaltz at altzman.com | www.jbaltz.com | twitter:@lorvax thank you for contributing to the heat death of the universe. From chsnyder at gmail.com Mon Jun 9 11:02:18 2014 From: chsnyder at gmail.com (Chris Snyder) Date: Mon, 9 Jun 2014 11:02:18 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <5395C836.6080100@altzman.com> References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: > > 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. >> > > For casual access, it's okay to just skip the password field altogether and use a token sent to email or sms as an authenticator. If you're building something that a user is only going to log into once a month or less, it may be less annoying to them to do an email roundtrip then it is to create yet another password. At the other end of the spectrum, I preach the gospel of the password manager to anyone who will listen. On a side note, I get annoyed at services that want to use Facebook or some other social network to log me in, because I don't necessarily want my account on one site to be linked to my account on another. As a user in that situation, I have to think about a whole raft of other issues: is this *really* Facebook's form, does the site get access to my timeline and friends, does Facebook have access to my account on this site, will my Facebook password still be on the clipboard after I log in, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daimmo at gmail.com Mon Jun 9 11:07:07 2014 From: daimmo at gmail.com (Pierpaolo D'Aimmo) Date: Mon, 9 Jun 2014 11:07:07 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: I had issues with FB authentication when trying to login from a mobile. Last time it happened it was with Grooveshark. I created the account with a FB login from a desktop, then tried to login on mobile and it was impossible, since their mobile interface doesn't use FB login. Pierpaolo D'Aimmo +1 201 892 1270 daimmo at gmail.com On Mon, Jun 9, 2014 at 11:02 AM, Chris Snyder wrote: > 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. >>> >> >> > For casual access, it's okay to just skip the password field altogether > and use a token sent to email or sms as an authenticator. If you're > building something that a user is only going to log into once a month or > less, it may be less annoying to them to do an email roundtrip then it is > to create yet another password. > > At the other end of the spectrum, I preach the gospel of the password > manager to anyone who will listen. > > On a side note, I get annoyed at services that want to use Facebook or > some other social network to log me in, because I don't necessarily want my > account on one site to be linked to my account on another. As a user in > that situation, I have to think about a whole raft of other issues: is this > *really* Facebook's form, does the site get access to my timeline and > friends, does Facebook have access to my account on this site, will my > Facebook password still be on the clipboard after I log in, etc. > > _______________________________________________ > 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: From rainelemental at gmail.com Mon Jun 9 13:55:44 2014 From: rainelemental at gmail.com (Federico Ulfo) Date: Mon, 9 Jun 2014 13:55:44 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: I share the same feeling on too pretending password rules: "Your password must contain a capital letter, a number, an emoji, 8 elements from the periodic table and a plot containing a protagonist with some character development and a twist ending." but I couldn't suggest to make password less restrictive and that's because too often people use the same password just with a small variation. A safer and easier solution is to offer Oauth with Google, Facebook or Twitter. I personally prefer to use my social to log everywhere because they're safe, (thanks 2 step auth!) and I don't have to use OnePassword, or any mental trick to remember all my passwords. So my suggestion is to implement a secure password policy and on top of that implement Oauth. On Mon, Jun 9, 2014 at 11:07 AM, Pierpaolo D'Aimmo wrote: > I had issues with FB authentication when trying to login from a mobile. > Last time it happened it was with Grooveshark. I created the account with > a FB login from a desktop, then tried to login on mobile and it was > impossible, since their mobile interface doesn't use FB login. > > Pierpaolo D'Aimmo > +1 201 892 1270 > daimmo at gmail.com > > > On Mon, Jun 9, 2014 at 11:02 AM, Chris Snyder wrote: > >> 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. >>>> >>> >>> >> For casual access, it's okay to just skip the password field altogether >> and use a token sent to email or sms as an authenticator. If you're >> building something that a user is only going to log into once a month or >> less, it may be less annoying to them to do an email roundtrip then it is >> to create yet another password. >> >> At the other end of the spectrum, I preach the gospel of the password >> manager to anyone who will listen. >> >> On a side note, I get annoyed at services that want to use Facebook or >> some other social network to log me in, because I don't necessarily want my >> account on one site to be linked to my account on another. As a user in >> that situation, I have to think about a whole raft of other issues: is this >> *really* Facebook's form, does the site get access to my timeline and >> friends, does Facebook have access to my account on this site, will my >> Facebook password still be on the clipboard after I log in, etc. >> >> _______________________________________________ >> New York PHP User Group Community Talk Mailing List >> http://lists.nyphp.org/mailman/listinfo/talk >> >> http://www.nyphp.org/show-participation >> > > > _______________________________________________ > 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: From bill.patterson1 at comcast.net Mon Jun 9 17:10:11 2014 From: bill.patterson1 at comcast.net (Bill Patterson) Date: Mon, 09 Jun 2014 17:10:11 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: <539622B3.8030406@comcast.net> I was once scammed by a site proporting to be using my facebook account and requiring my facebook user name and password. I thought I'd smell those situations by now but missed that one until my sister noticed some things originating from my facebook account that weren't like anything I'd send. Caveat user. On 6/9/2014 11:02 AM, Chris Snyder wrote: > > 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. > > > > For casual access, it's okay to just skip the password field > altogether and use a token sent to email or sms as an authenticator. > If you're building something that a user is only going to log into > once a month or less, it may be less annoying to them to do an email > roundtrip then it is to create yet another password. > > At the other end of the spectrum, I preach the gospel of the password > manager to anyone who will listen. > > On a side note, I get annoyed at services that want to use Facebook or > some other social network to log me in, because I don't necessarily > want my account on one site to be linked to my account on another. As > a user in that situation, I have to think about a whole raft of other > issues: is this *really* Facebook's form, does the site get access to > my timeline and friends, does Facebook have access to my account on > this site, will my Facebook password still be on the clipboard after I > log in, etc. > > > _______________________________________________ > 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: From ramons at gmx.net Mon Jun 9 19:04:20 2014 From: ramons at gmx.net (David Krings) Date: Mon, 09 Jun 2014 19:04:20 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <5395C836.6080100@altzman.com> References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: <53963D74.7090105@gmx.net> 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 At that point why bother with a password at all? And why use passwords? That's 60s tech...unfortunately, there was nothing invented since then that is easily created and entered using standard devices such as a keyboard. If you require a password, ask for a complex password and have strict and tight rules. Otherwise don't ask for anything. And for those who can't remember a password that is made up from a phrase like Th1$1sM?P8ssw?rd (where a German keyboard layout comes in handy), there is stuff like MaskMe or any one of the other password generators and managers. And then also secure the channel, out of the box SSL isn't cutting it anymore today. And yes, store the password salt somewhere else, not in the same table. >> 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. > 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. > >> If you use password authentication for user accounts, then base your rules >> on your needs. Site owner/Super Admin/Developer accounts should require >> complex passwords and two factor authentication. Day to day site manager 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. >> 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. > >> Every time I browse around to some interesting looking website where I have >> to "create an account" to access something I get increasingly upset at those >> sites trying to force their idea of security on an account that I don't care >> about. If I decide I want to actively use the site and am giving it >> sensitive information, I will change that password to something complex. If >> I never return to that site, then I don't care about the account. Depending on the site I either use BugMeNot.com or sign up using MaskMe and 10 minute mail. If I find the site / service to be worthwhile I close the fake account and craft a real one. > 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. David From jbaltz at altzman.com Tue Jun 10 09:26:47 2014 From: jbaltz at altzman.com (Jerry B. Altzman) Date: Tue, 10 Jun 2014 09:26:47 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <53963D74.7090105@gmx.net> References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> <53963D74.7090105@gmx.net> Message-ID: <53970797.5010302@altzman.com> 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. From rainelemental at gmail.com Tue Jun 10 09:55:57 2014 From: rainelemental at gmail.com (Federico Ulfo) Date: Tue, 10 Jun 2014 09:55:57 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <53970797.5010302@altzman.com> References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> <53963D74.7090105@gmx.net> <53970797.5010302@altzman.com> Message-ID: > > 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 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: From jbaltz at altzman.com Tue Jun 10 10:04:01 2014 From: jbaltz at altzman.com (Jerry B. Altzman) Date: Tue, 10 Jun 2014 10:04:01 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> <53963D74.7090105@gmx.net> <53970797.5010302@altzman.com> Message-ID: <53971051.7030800@altzman.com> on 6/10/2014 9:55 AM Federico Ulfo said the following: > > The notion of "I don't have FB, therefore nobody should force FB > auth" > > > Oauth should be an extra option not the only option!!! s/should force/should encourage/ > 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. Encourage, not force. But, in fact, small sites like StackExchange strongly encourage not creating local accounts: http://bit.ly/1uRbFj0 > 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. No argument there. //jbaltz -- jerry b. altzman | jbaltz at altzman.com | www.jbaltz.com | twitter:@lorvax thank you for contributing to the heat death of the universe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyamort at gmail.com Tue Jun 10 14:51:28 2014 From: garyamort at gmail.com (Gary Mort) Date: Tue, 10 Jun 2014 14:51:28 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <5395C836.6080100@altzman.com> References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: <539753B0.60405@gmail.com> On 06/09/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. > 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 definitely prefer using an external account.... going even a step further you can instead use SSL certificates and the keygen tag. While the ui is a little clunky on the browser side, on the server side it works perfectly. Just add a keygen field on your signup or user profile editor and when the user signs up/submits an edit the client will automatically generate and send a public key with the form. Server side you just need to format it into a certificate, sign it with your ssl key, and send the signed certificate back to the client. However, while I love all the alternates, the simple password logon isn't going away - so avoiding hardcoded rules and treating it as a binary string lets users choose what is convenient to them[I personally like to add a symbol of some sort, such as the copyright symbol ? - but most password systems are stuck to a limited aschii range] From garyamort at gmail.com Tue Jun 10 15:05:02 2014 From: garyamort at gmail.com (Gary Mort) Date: Tue, 10 Jun 2014 15:05:02 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> Message-ID: <539756DE.7000603@gmail.com> On 06/09/2014 11:02 AM, Chris Snyder wrote: > > 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. > > > > For casual access, it's okay to just skip the password field > altogether and use a token sent to email or sms as an authenticator. > If you're building something that a user is only going to log into > once a month or less, it may be less annoying to them to do an email > roundtrip then it is to create yet another password. > > At the other end of the spectrum, I preach the gospel of the password > manager to anyone who will listen. > Depends on the password manager and the person. Password managers which store everything locally have the risk of losing the file. Password managers where the data is stored in the cloud means that in all likelyhood all network traffic to and from that cloud server has been archived by one or more organizations. While the data archived is useless today, ten years from now it may be trivial to crack for them. Personally I'm not concerned about this, but then I am an introvert and not very involved with the world. :-) Someone active in a group like Amnesty International might be more concerned. And someone associated with political dissidents in China would defnitely have a good reason to be concerned. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramons at gmx.net Tue Jun 10 16:05:51 2014 From: ramons at gmx.net (David Krings) Date: Tue, 10 Jun 2014 16:05:51 -0400 Subject: [nycphp-talk] Relax your password rules In-Reply-To: <53970797.5010302@altzman.com> References: <539323CA.4020204@gmail.com> <5395C836.6080100@altzman.com> <53963D74.7090105@gmx.net> <53970797.5010302@altzman.com> Message-ID: <5397651F.1000107@gmx.net> On 6/10/2014 9:26 AM, Jerry B. Altzman wrote: > 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. Likewise I could claim that it is incorrect to conclude that just because you have an FB account everyone else has or should have one, too. Some sites insist on using only FB accounts or publish info only on their FB page that requires an FB account to view. Yes, that is their prerogative, but a pretty dumb move if the point is to get people to use your services. And given the security track record of FB I am not so sure if I'd call that securing anything. > >> 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. Landlines and dialup are still the only means of connectivity for many, especially in rural areas. Of course, if that is not part of the target audience then feel free to ignore it...and load up the pages with images and video. The numbers only slowly go down in favor of satellite or cell service. > We're also not optimizing the user experience for those using lynx... > Remember that you are not the world. Neither are you...my point is that by picking very specific 3rd party services to be used you exclude a good number of folks. If that matters is a case by case decision. > >>>> 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). Agreed, the gummibear trick showed that nicely. Which brings me back to the point that if something is so hot that it needs utmost security then the public web might be not the place that should be accessible through. --David From ioplex at gmail.com Tue Jun 24 00:08:40 2014 From: ioplex at gmail.com (Michael B Allen) Date: Tue, 24 Jun 2014 00:08:40 -0400 Subject: [nycphp-talk] Better Way to Secure HTML Forms with Hash Tokens? Message-ID: Hey, I've always used hash tokens in forms to sanity check POST requests. Meaning a random hash is generated on the server which is both stored in the session and emitted in a hidden field in the form so that when the form is submitted the server can remove it from the session and check it against the hash sumbitted with the form. If the client doesn't submit the one-time-token, there is no action taken. Just from Googling around it seems that this is fairly common, if not standard practice (Windows calls them "AntiForgeryToken"s). I found one claim that this actually thwarts CSRF and XSS although it seems to me that an attacker could use an async request to get a valid token before it submits the CSRF request. So I'm wondering if there is a better way. Specifically, my question is, is there anything about the legitimate request that would be reproducably different from the attacker's request (even though it was from the same browser instance - just not a page generated by the legit site) that could then be factored into the hash on the server? So does anyone have a clever technique they want to share (perhaps privately)? Mike -- Michael B Allen http://www.ioplex.com/ From felix.shnir at gmail.com Wed Jun 25 16:18:25 2014 From: felix.shnir at gmail.com (Felix Shnir) Date: Wed, 25 Jun 2014 16:18:25 -0400 Subject: [nycphp-talk] Better Way to Secure HTML Forms with Hash Tokens? In-Reply-To: References: Message-ID: One way of handling xss detection in your case would be to check if your form/page is being framed. Something like window.top != window would tell you that. Based on this, you could notify the server to invalidate one time token generated for this page if the page is in a frame. On Jun 24, 2014 12:09 AM, "Michael B Allen" wrote: > Hey, > > I've always used hash tokens in forms to sanity check POST requests. > Meaning a random hash is generated on the server which is both stored > in the session and emitted in a hidden field in the form so that when > the form is submitted the server can remove it from the session and > check it against the hash sumbitted with the form. If the client > doesn't submit the one-time-token, there is no action taken. > > Just from Googling around it seems that this is fairly common, if not > standard practice (Windows calls them "AntiForgeryToken"s). I found > one claim that this actually thwarts CSRF and XSS although it seems to > me that an attacker could use an async request to get a valid token > before it submits the CSRF request. So I'm wondering if there is a > better way. > > Specifically, my question is, is there anything about the legitimate > request that would be reproducably different from the attacker's > request (even though it was from the same browser instance - just not > a page generated by the legit site) that could then be factored into > the hash on the server? > > So does anyone have a clever technique they want to share (perhaps > privately)? > > Mike > > -- > Michael B Allen > http://www.ioplex.com/ > _______________________________________________ > 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: