Ignore CAPS-LOCK state when entering password

[Izhar Aazmi]

I suggest having a feature to allow for the following variations of password during user authentication.

Case 1: Assume the original Password is: PassWord@1

The acceptable variations would be:

PassWord@1 => Original password as it was set, obviously.

passWord@1 => First letter was capitalised by mobile device while setting password. 

pASSwORD@1 => Caps-lock state reversed during login.

PASSwORD@1 => Caps-lock state reversed AND First letter capitalised by mobile during login.

Case 2: Assume the original Password is: passWord@1 (first is lowercase)

The acceptable variations would be:

passWord@1 => Original password as it was set, obviously

PassWord@1 => First letter was capitalised by mobile device during login. 

PASSwORD@1 => Caps-lock state reversed during login

pASSwORD@1 => (umm, not sure)

1-3 are same for both cases. The 4th only applies to the 2nd case. But we don't know what case is the first letter in the stored password anyway! 

So all these four variants can be accepted as correct password. I am not sure whether this would even make sense in general. Therefore not created a PR yet, see my commit at izharaazmi@b6837f8 and let me know whether this should be a PR.

Facebook has this feature already for quite long. See http://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

[brian teeman]

NO!!!!

the only password that should ever be accepted is the 100% correct password. Anything else reduces the entropy of the password and makes it immensely easier to brute force.

Even then your example do not match the way Facebook do it. For example first letter uppercase is only on a mobile device. It doesn't work on a desktop.

[Izhar Aazmi]

NO!!!!

the only password that should ever be accepted is the 100% correct password.

 

Anything else reduces the entropy of the password and makes it immensely easier to brute force.

I understand that this reduces the entropy. Still I think if this was really that much a big as an impact would Facebook adapt it?

 

Even then your example do not match the way Facebook do it.

Yes, and I can match it if we really are into it. For now it is a quick code and example to present my opinion. We may also come up with slight varying ideas here than Facebook.

 

For example first letter uppercase is only on a mobile device. It doesn't work on a desktop.

 

Does it really matter? Device can usually be spoofed / emulated. However it is still better to implement this. 

On the other hand we can just skip first letter caps handling altogether and just accept toggle case version.

 

[Michael Babker]

Just going to repeat Brian here, "the only password that should ever be accepted is the 100% correct password"

The second you start accepting case insensitive passwords you have introduced a major security breach into your system.  Period.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Sergio Manzi]

The method used by Facebook removes less than two bits of entropy from the password.

If  really concerned about the reduced entropy, one could much more than compensate for that by simply adding an extra character.

Please see: https://news.ycombinator.com/item?id=3920918

[Michael Babker]

The method used by Facebook is a security flaw, period.  It has introduced case insensitivity into the password mechanism.  Going into my password generator, the password it just generated for me is this:

4P{z4k8nvbL2ow,.8nq;$G^@.8Dai9P9

Per the referenced post (and its references), all lowercase characters in that string are in essence case insensitive; if I submit the same string with all capitals I am successfully authenticated.  Great for the user who leaves caps lock enabled, but it is hands down a security issue and shouldn't be considered as anything but.  If anything this tells me I should reconfigure my password generator to use as few alphabetic characters as possible so as to prevent systems which accept this moronic idea from compromising my account.

[Sergio Manzi]

I'm afraid you're not getting the point:

When you said "if I submit the same string with all capitals I am successfully authenticated", that's will absolutely not be the case.

To be successfully authenticated you have to flip the case of every letter. The alternative good password would be:

4p{Z4K8NVBl2OW,.8NQ;$g^@.8dAI9p9

It is not about case in-sensitiveness as you are implying, here and on Twitter.

[Michael Babker]

Even if it's reversed case it has still introduced case insensitivity logic into the handling.  The point is if my password is CompleteAsshole then I expect that only CompleteAsshole is allowed.  Not completeAsshole or cOMPLETEaSSHOLE, period.  Any variation of my password that is accepted which is not my password as a 100% match is a security flaw, period. 

[brian teeman]

Why don't we just change it so we only check the number of keys pressed. That way even if you hit the wrong key because you have fat fingers you will still be authenticated

[Sergio Manzi]

Yes, 1 bit of reduced entropy. A little bit more (but less than two 2bits) with the Facebook logic that apply a special treatment to the first character (if alpha). An extra alpha character, by comparison, adds about 6 bits of entropy.

And again you cannot talk about "case insensitivity logic into the handling": that's specious.

The logic for what Facebook did (and with which I'm not sure I concur, I have to think it over...) is to reduce the number of password resets due to password wrongly entered because of CapsLock being inadvertently be engaged. This what a Facebook spokesperson had to say about this:

"Our passwords are not case insensitive. We accept three forms of the user's password to help overcome the most common reasons that authentic logins are rejected. In addition to the original password, we also accept the password if a user inadvertently has caps lock enabled or their mobile device automatically capitalizes the first character of the password. We feel this does not significantly impact the security of the user's password or their account."

[Michael Babker]

"We accept three forms of the user's password"

That's the smoking gun right there.  Their system does not enforce 100% exact match, but rather as a measure of convenience, allows certain variations due to user error.  So it is an acknowledgement that they have introduced a security flaw in favor of user experience.

I don't give a crap how convenient it is.  The day this gets merged is the day I will personally fork Joomla, I don't care if I have the resource to make it sustainable or not I will NOT develop on, endorse, or support a platform which blatantly compromises security because some moron can't figure out how to use their shift and caps locks keys.

[Sergio Manzi]

As you wish, but you can't treat people like idiots (with corresponding Tweet) when what is proposed is not the end of the world and good enough for none less that Facebook...

[Michael Babker]

Actually I can.  Would you feel this comfortable with such a completely moronic thing if it was your bank account we're talking about here?  Or PayPal?  Or something like Amazon or eBay?  I sure as hell wouldn't.  I have enough identity issues with having had 2 credit cards ripped off in the last 3 years as well as a lot of personal data stolen by way of a US Government breach.  The last thing I will EVER accept ANYWHERE dealing with my identity and my authentication routines is a compromise in password matching.

[Sergio Manzi]

Honestly yes, because all my passwords have at least 60 bits of entropy and reducing it by less than 2 bits wouldn't harm much.

In things like that math is what count, not guts.

[Leo Lammerink]

I actually agree with Michael and Brian here. We cannot tolerate or adapt any way of reductions of pw security. Just going to repeat Brian here, "the only password that should ever be accepted is the 100% correct password" and despite Michael's reaction being rather strong... I do agree with it's merit. No compromises on pw security at all costs whatever math somebody uses to justify his opinion!

Leo

[Chris Davenport]

If the aim is to reduce the number of password resets caused by CapsLock being left on, then perhaps surfacing that information to the user will help, without compromising security.  Could we add a bit of JavaScript to the login form which detects CapsLock state and displays a simple warning message if its on?

Chris.

Chris Davenport
Joomla Production Leadership Team

[Michael Babker]

Should be able to.  http://stackoverflow.com/questions/4810454/how-do-i-detect-the-caps-lock-state-in-a-password-field

- Michael

Please pardon any errors, this message was sent from my iPhone.

[Leo Lammerink]

I hear you Chris but isn't that prone to vulnerabilities? Manipulate the JS and you override that easy perhaps?

Leo

[Izhar Aazmi]

Sorry to bring such a stupid topic here. I didn't know it was.

Accept my apologies for not being able to judge my idea before posting. Probably I should try to keep my childish ideas away, and stay limited to bug fixes only. Or at least keep away from any new ideas unless I'm more than double confident.

Please stop bursting the rage over me on Twitter or anywhere. I'm sorry.

I just wanted opinions and not a merge. That was not a PR, Reason? What else could be.

[Chris Davenport]

It doesn't affect security at all.  It's merely telling the user that they accidentally left CapsLock on and they should probably switch it off if they expect to enter the correct password (whatever that might be).

Chris.

[brian teeman]

Chrome and Safari already display an indicator in any password field when caps lock is on

Dont know about any other browsers

[brian teeman]

Also don't know about iOS but android does not try to capitalise the first character in a password field.

[Brad Gies]

I think you're missing the obvious point.... most mobile phone IME's automatically capitalize the first letter of a sentence (which means you have to actually uncapitalize the first letter of your password on your phone)...

What Facebook is doing is reasonable, and an acknowledgment that the internet needs to mobile first as of 2016...

You don't have to like it... but you can expect to see it in most mobile enabled apps going forward.... but Joomla! likes to be behind the bleeding edge, so be it.

Cheers,

Brad

[Richard Fath]

I think that's the best idea, I like that because I have very fat fingers :D

[Brad Gies]

You're missing the obvious point (and most important point).... What Facebook is doing is acknowledging that the internet is now a mobile first world, and that the majority of their users keep up to data on their mobiles.

Most mobile IME's automatically upper case the first letter of a sentence, which results in a lot of mobile users entering their password wrongly without knowing.

Joomla! is not that mobile friendly anyway, so no need to follow Facebook on this one.

I think it's a great feature for mobile friendly apps, but that's not Joomla!'s niche.

Brad

On 2016-07-03 1:10 AM, Sergio Manzi wrote:

[Chris Davenport]

If that really is the behaviour you are encountering then I'd classify that as a bug in the mobile device OS and it should be reported as such.  The mobile must know it's a password field so it has no business overriding what the user enters.

Chris.

[Sergio Manzi]

Safari apparently consider that particular aspect (auto-capitalization) not as a bug but as "feature". It can be turned off if needed.

See: https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocapitalize

[Sergio Manzi]

Actually a bug, as they say:

... the default value is sentences for form and none for input elements with type set to password as in <input type="password">.

!

[brian teeman]

So both iOS and android do not capitalise password fields. Time to move on with real issues.

[romacron]

thx a lot. this discussion has no future

[Brad Gies]

Well... your IME might not, but many do... maybe you just haven't tried all of the more than 200 IME's just for iPhones, and some work differently for different languages... I think there are more than 800 for Android.... anyway... below is what Facebook says....

A Stack Exchange thread pointed me to this ZDNet story that explains why Facebook allows users to login through multiple passwords. According to Facebook:

We accept three forms of the user’s password to help overcome the most common reasons that authentic logins are rejected. In addition to the original password, we also accept the password if a user inadvertently has caps lock enabled or their mobile device automatically capitalizes the first character of the password.

[Brad Gies]

Well... I don't use Facebook much, and my IME doesn't do it... but I do a lot of mobile development, and it's fairly well known in the mobile world that many IME's capitalize the first letter... should they... no... but there are millions of apps out there, and thousands of IME's.... anyone can install any IME they want... and any app can use a different IME.

If you and Brian just need (crave) your flame war, have it with Facebook. I just told you the reason, because nobody on this list seemed to know. No point disagreeing with me... I'm not taking a stand either way... just reporting the facts... if you want (need?) to shoot a few more flames at me... go ahead.... some people don't like facts ;)

Brad

[Chris Davenport]

Hardly a flame war.  I'll take your word for it being a problem.  I certainly wasn't aware of it.  But whatever workaround is proposed must not weaken the security of any existing users/sites.

Chris.

[brian teeman]

Can you provide some evidence of a mobile device web browser that capitalises a password field.

[Sergio Manzi]

Guess this could be on of those rare cases where having a "switch" to select the proposed behaviour could be a viable possibility...

(I said "switch" as I'm trying to avoid the forbidden "O" word, which could ignite a fresh new salvo of pyrotechnic flames...)

[Michael Babker]

No switch, no option, no changing the behavior of the freakin' HTML specified password field.  If you have to do that then frankly the browsers screwed up and if users can't pay attention to that issue then they need to be educated.  Period.  I seriously can't believe this whole damn thread is still ongoing.  Next thing you know it there's going to be a suggestion to remove all the password fields in core to use plain text to make sure people can enter their damn passwords correctly because it's so much more user friendly to see your plain text password versus a bunch of dots.

Drop the subject.  Or go find a platform that doesn't care about user security to throw these asinine ideas at.  Seriously, this is going on far too long.

[brian teeman]

Anyway there is a really really easy way that doesn't require any JavaScript at all that both iOS safari and android chrome will accept to prevent autocapitalising I will do a pr in the morning

[Sergio Manzi]

Mission not accomplished: running to wear my Nomex coverall.

[Sergio Manzi]

That's a good idea, but, as far as I understood from what Brad wrote, that will not cover the whole spectrum of problems

[Sergio Manzi]

OK, here I am, I dressed the Nomex coverall.

Sorry but:

• You have been mathematically demonstrated that the proposed behavior (btw, I'm not the one who proposed, so you missed the target with the "Asinine" this time) has a minimal effect on system security
  
  
• You rebut with... figuring out scenarios of profoundly affected security
  
  
• Every time you (both Brian, with the "counting the keystrokes" thing, and Michael, with the "visible passwords" thing) submit the proposed behaviour to the test of a very well known rhetorical figure: "Reductio ad absurdum" (https://en.wikipedia.org/wiki/Reductio_ad_absurdum)

Just a question, what's the real problem?

[Michael Babker]

The real problem, whether it is mathematically so minimal an issue that it is acceptable to some, is that it introduces rules which favor user experience over security.  If I fat finger a password, be it because I left caps lock on, my iPhone was overzealous and autocorrected or auto capitalized something, or any other thing that would result in a non-100% match to my original password, I expect to be told that my password is wrong and try again.  That means I need to pay closer attention to what I'm doing.  That doesn't mean I need to have applications rewritten to accept ANY variation of my password because of my thick headedness or some third party with overzealous behaviors changing my input.

I don't care how comfortable you, Facebook, or anyone else is with that.  One password for one account.  Not three.  Not two.  One.  Period.  Anything else, even if we're talking about one bit, is a security flaw.  Period.

Don't like my hard up stance?  Tough luck.  I do not agree with compromising security for ANY reason WHATSOEVER.  And this is an admitted compromise of security, whether it is mathematically insignificant or not.

--

[brian teeman]

As stated above the proposed solution is wrong and there is a better one provided by the browsers to address the problem without changing passwords or effecting security and ensuring that only what the user types will be accepted for a password.

[Hannes Papenberg]

Just because I didn't speak up yet, doesn't mean that I would agree to this idea. Sorry, but this is simply a stupid idea. If you want to have this for your site, feel free to implement your own authentication plugin that behaves in this way, but it is a complete no-go for the joomla core. We have a duty to our users to make the software as secure as possible and knowingly weakening something as essential as the authentication system is simply unacceptable. I agree 100% with Michael here.

If you want to provide this feature to others, feel free to provide it as a third party authentication plugin, but be prepared to handle the fallout. Are you claiming to know all implications? I don't. Not only does it weaken the password, it might also introduce other weaknesses like implementation bugs, timing attacks or similar. I'm definitely not willing to take that risk.

Hannes

[Sergio Manzi]

I understand your position, but, as I suppose many others (end-users and web designers in the max part, I think), beg to disagree.

You prefer the maximum obtainable security over a very small compromise that favor end-user UX.

This, in my books, should be "debatable" and not treated as asinine.

[Michael Babker]

Convenience over security should be debatable!?  GTFO.  Where's the whiskey…

[Sergio Manzi]

... yet another "reductio ad absurdum".

What is proposed has been adapted by Facebook, and I don't think they were all buzzed-up when they took that decision, unless you know better.

[Sergio Manzi]

adapted = adopted, sorry,

[Hannes Papenberg]

The history is full with such "cool" ideas that compromise security just a tiny bit for UX/profit/world peace and which fucked them later big time. If you take security seriously, there is no compromise. If you don't, then I have no business in this project anymore.

[Ole Ottosen (ot2sen)]

Security never is to argue.

It is like "I don´t need my seat belt, it is only a short drive. More convenient" Nevertheless, just as dangerous.

Lazy or convenient FB users can learn from Joomla. Uppercase is not the same, just like o is not u nor i.

Happy to see the security squad giving this a fight :)

[Michael Babker]

I don't care if Facebook or Hilary Clinton find it an acceptable risk.  I don't.  And I will fight tooth and nail against such a thing ever being merged.  This goes against every common sense test or any bit of training I ever received on matters of security and information assurance.

[Milton Bryant]

Yes, but Joomla! isn't Facebook. I'm sure Facebook has a fleet of really expensive and skilled lawyers on retainer in case one of their billion or so users wanted to sue them because their account was compromised through the slight risk introduced intentionally by the development team.

[Sergio Manzi]

then you should ENFORCE minimum 12 chars password with a mix of characters (upper AND lowercase), numbers, and symbols.

... or maybe just an extra char would suffice.

[Michael Babker]

When I'm in charge of security policy I do that.  I also limit account accesses to minimum required to perform a job, or if possible make something work so that user accounts aren't needed at all.  Things that sadly I can't dictate beyond my own spaces.

[Sergio Manzi]

... but you want to dictate other policies that have a far lesser impact.

Joomla allows me to use "smz" as my password: 9.2 bit of entropy (crap!!)

I want to be sure and make it "smz1": 14.2 bits

Apply Facebook algorithm: 14.2 - 1.59 = 12.61

better than "smz"!!!

[brian teeman]

Stop trolling.

I'm going to bed and in the morning will submit a pull request that solves your imagined problem and does not change passwords

[Sergio Manzi]

I sincerely feel I'm not trolling.

[Ole Ottosen (ot2sen)]

YOU CAN NEVER EVER IGNORE CAPS. Simple isn´t it :)

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[Sergio Manzi]

Sorry? Have I used all-caps???  :-/  where??

To post to this group, send email to joomla-...@googlegroups.com.

[Michael Babker]

Password strength rules are different from server side processes which weaken the user password.  I'd actually suggest that Joomla borrow the logic from WordPress' installer to give the user a default secure password and to enable the password strength rules there but sadly the password rule class to enforce that server side is dependent on com_users config so totally unusable in the install app.

[Sergio Manzi]

> Password strength rules are different from server side processes which weaken the user password

No, they aren't: that's mathematically irrefutable.

With the rest.... you know what? I agree. And it could be a very good improvement.

[Brad Gies]

Sergio,

I agree whole-heartedly. It is a tiny, insignificant difference to password strength, and is easily more than offset by simply add one more character to your password :) 

I don't expect, or even want Joomla! to follow Facebook for this.... but I definitely agree with Facebook doing it. Facebook is something that a lot of people depend on daily (not me... I log into Facebook about 3 times a year) and for many people, being locked out of their Facebook account for an unknown reason causes a tremendous amount of work for Facebook support reps....

It's not something that Joomla! (or any other framework) should do as a default, but it is something that mobile-centric applications should consider. After all... Facebook lists having caps lock on, and IME's capitalizing the first letter as the two things that stop legitimate users from logging in.... and they've got enough users to have good stats.

I'm not changing my websites to have the 3 passwords.... but now that Facebook has done it.... I will definitely be doing it for my mobile apps ;) (was scared to do it before, but now that Facebook has done it, it will become common).

I'm guessing that Michael has cancelled his Facebook account by now.... :).

Brad.

[Brad Gies]

No... but I'm sure Facebook can....

I can give you anecdotal evidence.... one of my previous phones had that
annoying behaviour, and Facebook lists it as the second most common
cause of legitimate logins being denied. I just don't have the time to
prove something to you, that is common knowledge in some programming
circles... if you care, google it.

OR... even better.... Let me know when you have tried all the IME's
available... it would be handy to have the statistic on how many
capitalize the first letter for passwords...


On 2016-07-04 5:30 AM, 'brian teeman' via Joomla! CMS Development wrote:
> Can you provide some evidence of a mobile device web browser that capitalises a password field.
>

[Chris Davenport]

@Brad.  My curiosity has got the better of me... what exactly is an IME?  It's not a term I've come across before and googling didn't reveal anything that looked relevant.

Chris.

[Brad Gies]

"Input Method Editor", but many people use "Input Method Extension" .... Android (and Apple) allows users and apps to download any IME they want....and any program can build their own if they want.

Basically... if you use a Chinese IME, you get a box like the English one... but as you type Pin Yin (english version of Chinese)... it shows the corresponding Chinese characters below the the box... when it selects the one you want, you can push enter to input it into the text box.... most Chinese IME's show a selection of chinese characters that potentially match what you input...

Here's a simple one.. This is what a Chinese user of Google uses to search (if they get through the Great Firewall)... there are many, but this is a simple one that only uses Pin Yin when typing... many also have boxes beside them to draw the Chinese character:

Basically, you type "ni hao"... and the corresponding Chinese characters (for "Hello")... show up.

BUT... it should be noted that the IME itself normally does not know what called it.... it's simply a component that is called and passes back the results to the calling program....The program should deal with the results properly... many don't...

[Chris Davenport]

Interesting.  Thanks for the explanation.  I appreciate it.

Chris.

[brian teeman]

I'm not changing my websites to have the 3 passwords.... but now that Facebook has done it.... I will definitely be doing it for my mobile apps ;) (was scared to do it before, but now that Facebook has done it, it will become common). 

Facebook did it in 2011 - thats FIVE years ago

[Sergio Manzi]

Time tested, then. And the sky has not fallen yet.

On 2016-07-04 12:52, 'brian teeman' via Joomla! CMS Development wrote:

I'm not changing my websites to have the 3 passwords.... but now that Facebook has done it.... I will definitely be doing it for my mobile apps ;) (was scared to do it before, but now that Facebook has done it, it will become common). 

Facebook did it in 2011 - thats FIVE years ago

[brian teeman]

To put the icing on the cake. Did anyone try to see if Facebook still do this in 2016 ??

I just did and guess what the only password that was accepted was my exact password

[Sergio Manzi]

Sorry, can't test as I don't have a FB account, but how have you tested? From your MacBook? Couldn't it be that they did it in their "Apps" only?

On 2016-07-04 13:01, 'brian teeman' via Joomla! CMS Development wrote:

To put the icing on the cake. Did anyone try to see if Facebook still do this in 2016 ??

I just did and guess what the only password that was accepted was my exact password

[brian teeman]

https://github.com/joomla/joomla-cms/pull/11017

[Sergio Manzi]

Thanks, Brad.

I haven't a FB account and I haven't an IOS device (actually I don't even have a modern smartphone, being loyal to my old BlackBerry Bold):  can you test if this little CSS does the trick, at least as far as regards the autcapitalization issue?

input[type='password'] {autocapitalize:off;autocapitalize:none;}

Cheers,

Sergio

[Sergio Manzi]

P.S.: can you please also try using the "-webkit-autocapitalize" CSS attribute?

P.P.S: if the proposed CSS does work, only the "flip the case" part of the game would suffice to fix the CAPS-LOCK issue, reducing the entropy loss to a mere "1 bit"

[wdburgdorf]

If this option was sold as a plugin, I'd buy it and install it on every client site. I'm following the math, and client happiness logic. Accepting truely "moronic" passwords like 123456 or somebodies dogs name or date of birth etc. is a much greater flaw than accepting four varieties of a really good password.

I appreciate that you guys care about security and I understand that Michael had some bad experiences and therefore uses paranoidic passwords like 4P{z4k8nvbL2ow,.8nq;$G^@.8Dai9P9 - but try to remember this by heart or type it in from a piece of paper. And yes, many people still write down their passwords on paper. Many people don't know about copy/paste and cannot be bothered to use KeePass et al. Call these people "morons" if you like, I call them valued customers.

Am Samstag, 2. Juli 2016 12:26:55 UTC+2 schrieb Izhar Aazmi:

I suggest having a feature to allow for the following variations of password during user authentication.

Case 1: Assume the original Password is: PassWord@1

The acceptable variations would be:

PassWord@1 => Original password as it was set, obviously.

passWord@1 => First letter was capitalised by mobile device while setting password. 

pASSwORD@1 => Caps-lock state reversed during login.

PASSwORD@1 => Caps-lock state reversed AND First letter capitalised by mobile during login.

Case 2: Assume the original Password is: passWord@1 (first is lowercase)

The acceptable variations would be:

passWord@1 => Original password as it was set, obviously

PassWord@1 => First letter was capitalised by mobile device during login. 

PASSwORD@1 => Caps-lock state reversed during login

pASSwORD@1 => (umm, not sure)

1-3 are same for both cases. The 4th only applies to the 2nd case. But we don't know what case is the first letter in the stored password anyway! 

So all these four variants can be accepted as correct password. I am not sure whether this would even make sense in general. Therefore not created a PR yet, see my commit at izharaazmi@b6837f8 and let me know whether this should be a PR.

Facebook has this feature already for quite long. See http://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

[Sergio Manzi]

Thanks, wdburgdorf.

Geee... I really hope nobody will jump on this idea and make a commercial plugin out of it!

Just to correct a minor "ab-initio" error, if this "mistake tolerant" password checking should be implemented, the alternative versions to check are just 2 and not 3. You have to check:

• The password "as entered".
• The "flipped case" password.
  
• The password "as entered" but with the char at position 0 lower-cased.
  

I think there is no point in testing the "flipped case" password with the char at position 0 lower-cased.

And again, if the proposed CSS does indeed work, then only the alternative "flipped case" password should be "extra-checked".

Instead of using CSS, a better solution could be to inject the attributes via JS (a dedicated JS, or perhaps jquery.ui.core.js) so that all templates could benefit of it.

[Michael Babker]

... I give up.  All I'm getting out of this thread is a list of people whom I would never trust with my data because they feel customer convenience outweighs security every day.  If you compromise on passwords, what stops you from compromising on secure storage mechanisms with other personal credentials, or payment data?  I don't care if it is only one bit, it makes a statement about your priorities and that a secure platform is not one of them.

[Sergio Manzi]

> ... I give up

I'm sorry.

> All I'm getting out of this thread is a list of people whom I would never trust with my data because they feel customer convenience outweighs security every day.

Reductio ad absurdum (and mildly offensive)

> If you compromise on passwords, what stops you from compromising on secure storage mechanisms with other personal credentials, or payment data?

Reductio ad absurdum

> I don't care if it is only one bit, it makes a statement about your priorities and that a secure platform is not one of them.

You have a point here: there could be persons that, either because they don't know what they are talking about or because in bad faith, could leverage this for attacking Joomla. That's why I proposed this behavior as an option and not set it as the default.

[Michael Babker]

It's the fact you want to give people that option that troubles me most.  I don't care if it's the best of intention, I don't care if the risk factor is minimal, it is still a risk, it is still a compromise, and in any place I've worked that has any reasonable security measures such a rule would never make it out of the discussion room.

I come from a background working in secure facilities, I have training as an Information Assurance Security Officer, and I'm that asshole that had to turn off the accounts for "important" people for failing to complete mandatory training or for compromising data and/or our networks for one reason or another.  Everything in my 11 years of professional experience working in predominantly security and system administrative roles tells me that this is nothing short of a security risk and I do not find it acceptable.  If you feel like the fact that I'm saying it's a stupid idea, no matter who supports or has implemented something similar previously, frankly I don't give a damn.

As explained before, I have had several data compromises, including one from a government agency who I was supposed to be able to trust to use the highest security measures with said breach not only compromising my personal identity details, but potentially those of a dozen other individuals who did absolutely nothing except get to know me.  So when I see anyone campaigning for any feature which weakens a platform's security in any way, even if it's optional, quite frankly that raises a red flag with me and immediately blacklists them from trusting with any personal data beyond my name and email address.

[Sergio Manzi]

Michael,

I don't want to offend (especially not as somebody did to me elsewhere, at the edge or beyond the edge of penal relevance), but what I'm getting from your story is that you've been badly bitten in the past or have been deeply inculcated with the concept that "not even a bit of additional risk" is acceptable.

I concur that this could be the case in some cases, but making out of it a general unbreakable law, to me that means that one takes decisions more listening to his guts feelings than exercising his intellectual faculties, especially as nothing in Joomla prevents one from using what you'll probably call asinine passwords.

[Michael Babker]

I never called the passwords asinine.  The process of accepting an alternative password that is not a 100% bit for bit match of the user's supplied password is what I consider asinine.  Note I also generally discourage the use of weak passwords but alas you can't force everyone to use strong passwords, a password manager, and get past the days of using the same password for everything, writing them on sticky notes attached to your monitor, or the other "stupid" mistakes people make unless you move to a system that doesn't use passwords (but that's not even foolproof, I can't tell you how often someone else handed me their ID card and told me their 6-8 digit pin number to be able to do something with their account since our systems stopped supporting username/password authentication, AND THIS WAS ACCEPTED PRACTICE!).

To me this proposal falls into the "general unbreakable law" category because it prioritizes user convenience over account security.  Yes, I'm fully aware we're talking about bits here, you've beaten that dead horse back to life.  But it to me is still an unnecessary risk to accept.  I don't agree with weakening a system's security just to make things easier for the end user.  The user interface should be crafted in such a way that the platform's security measures don't require any form of compromise or a systems administrator signing off on an added risk as acceptable.  Short of rewriting OS/browser behaviors to better handle the caps lock state while in a password input field (which would be an inconvenience too, I can't tell you how often I ran into someone with a password of 123456!@#$%^qwertyQWERTY and would use caps lock for the last bit of that sequence), the only options are to either compromise account security (by bits, since we seem to need to reinforce that argument), better train users on awareness of what's being typed (including watching for stray things like that shift indicator or auto correct trying to change something), or petitioning W3C and every major vendor to change the behavior of password fields in a more user friendly way.

[Sergio Manzi]

I was about answering with a "My turn giving up!", but no, that wouldn't be fair and it would be offensive to your intelligence.

The keyword phrase in your long answer is:

To me this proposal falls into the "general unbreakable law" category because it prioritizes user convenience over account security.

And that's exactly what I'm confuting: isn't this exactly the same as not enforcing a minimum password entropy?

It is for user convenience that we do not enforce a minimum password complexity and/or two factors authentication and we leave users the freedom and responsibility of adopting their security rules. Why should this proposed option be seen any different?

=====

You insist in calling "asinine" something you don't agree with (while others do). Sorry, but this should not be allowed here, not even to a column of the community like you are. There are dozens of way for saying you do not agree or even consider this a very-very bad idea without recurring to offensive and inflammatory adjectives.

Especially "as a" column of the community you should mind your language better, I think.

[Michael Babker]

On Tue, Jul 5, 2016 at 10:19 AM, Sergio Manzi <s...@smz.it> wrote:

And that's exactly what I'm confuting: isn't this exactly the same as not enforcing a minimum password entropy?

It is for user convenience that we do not enforce a minimum password complexity and/or two factors authentication and we leave users the freedom and responsibility of adopting their security rules. Why should this proposed option be seen any different?

Joomla core should by default ship with a stronger ruleset than it does now, but ultimately Joomla shouldn't prevent someone from using "hello" as their password as it's ultimately the choice of the end user and system administrator.  Can't say I agree with that but ultimately it should be the user's choice what their password policy for the site is.  The best we can do is encourage strong passwords and right now we fail to do that by not shipping with a strong password policy enforced by default or even turning on our password strength meter option.

You insist in calling "asinine" something you don't agree with (while others do). Sorry, but this should not be allowed here, not even to a column of the community like you are. There are dozens of way for saying you do not agree or even consider this a very-very bad idea without recurring to offensive and inflammatory adjectives.

I call it as I see it.  Sorry (not sorry) if it offends, but I will not sugarcoat my opinion about things, especially when it pertains to security matters.

[Sergio Manzi]

On 2016-07-05 17:38, Michael Babker wrote:

I call it as I see it.  Sorry (not sorry) if it offends, but I will not sugarcoat my opinion about things, especially when it pertains to security matters.

It is not a matter of sugarcoating, but respect or lack thereof.

If you don't get this point, I will give up on this: evidently there is nothing more I can do convince you that lack of respect is incompatible authoritativeness.

As for the rest, yes, the horse is dead (or live and doing well) and everybody's free to make up his mind.

[Sergio Manzi]

sorry, meant to say "incompatible with authoritativeness"

[kisswebdesign]

I'm with Michael on this issue.

Joomla should be as secure as possible by default, with no core option to degrade it.

Any decisions to make it less secure (even by 1 bit) should be an active design and development decision by the site owner. As is the password policy.

A 3rd party plugin to implement this is OK (and might be popular), but not for the core joomla product.

I cannot force people to use secure passwords (although I would if I could), but I can ensure that the password chosen is the only one that lets them login.

If you value users over security, and can argue that making your website less secure for the sake of users (and your website support team) then go for it - there may appear be a financial saving in doing so (until your decision to lower the security causes a breach, and have to pay fines or get sued).

Just like I don't want a key that is almost the same as mine opening my door (house, car, shed, whatever), even if it my "almost the same" key that looks the same on my keyring. I will only be happy if the right key opens the right door, even if it is inconvenient and I have to try twice (or more) to get the door open. The same applies to my websites.

[Sergio Manzi]

As apparently this idea will never see the light under the official Joomla auspices, but there has been some interest around it (especially for such a "3rd party" plugin), I created a "relaxed" authentication plugin that implements the ideas originally expressed in this thread.

The code is based on the official Joomla authentication plugin but it has been modified to accept not only the "true" password, but also the "capitalized" form and the "flipped characters case" form.

As this is thought as a plugin that will be voluntary installed by those needing this relaxed authentication, no "option" has been implemented. The plugin does just what it says: it uses the "relaxed" form of authentication above described. Use it or don't use it, at your choice, will, and risk.

I dedicate this to whomever might be interested and I'm only asking for a thorough test (especially by those using a non-latin character set in their passwords) and PRs in case of mistakes or need of changes.

The code is at: https://github.com/smz/plg_authorization_relaxed

Many thanks to everybody who contributed to the discussion.

smz

P.S.: absolutely no offense is meant to the "dissenting party", whose opinions I respect even if I profoundly disagree, and of course this should not be seen as a "Joomla fork". This is just what it is: a different, relaxed,  authentication plugin, part of the Joomla "echosphere", offered for free to whomever might find it useful for his/her own purpouses.

[wdburgdorf]

Thank you, Sergio! I installed it and tested it briefly, and so far it seems to work just fine. 

In contrast to Sergio, I do not profoundly disagree, but profoundly agree with the opinion of those who want to keep Joomla as secure as it can be, especially Michael. I am really glad that Joomla has developers who are dedicated 100% to security and who are also 100% competent. 

"... if it was your bank account we're talking about here?  Or PayPal?  Or something like Amazon or eBay?  I sure as hell wouldn't." - Neither would I. I know that I am no security expert, so I do not handle any truly security relevant data for anyone. No credit card data ever. On most sites, the only personal data is names and e-mail addresses, mostly publicly available anyway. And I know some of my client's personal passwords - literally their dogs name, or similar. For these sites and clients, convenience is indeed a much higher priority than losing 1 bit of password security.

So I thank Michael et al. for keeping core Joomla safe, and Sergio et al. for providing the opportunity to knowingly sacrifice some security for convenience - and client happiness.

[Troy Hall]

Sergio, ty for making the name of this plugin easy to ban from my servers.
Bear