Madness (present world)

[Pallid Planetoid]

A bit of deductive logic to discuss regarding computer "security" (if you don't want to read the entire post, then just confine your read to designated section at the top of the post (above the "=====" divider) for an interesting read on how we can all get things so wrong so often and still just go along totally absent (for the most-part) of any thoughts on the subject....

As we all know - virtually everyone abides by a "rule" that it's best to change passwords on a regular basis (i.e. every few months).
Lets consider this "false logic" ("false" is undoubtedly conclusive by taking into consideration the entirety of the premise as stated below in detail).
Premise:
1) assuming that we all (each of us) start out with a password that is optimally secure as far as what would be considered a fully adequate password. (keeping in mind, why would this NOT be the case? - clearly it would NOT be the case to NOT presumably start out with what would be considered an "optimally" secure password - because, why would anyone NOT, to the best of their knowledge, use a fully adequate password in the first place? So the changing of a password on a regular basis would NOT be for the purpose of improving on an already "fully adequate password" presumably put in place by the user - everyone agree? (based on the solid premise as stated)
2) so the assumption that it's a good practice to change passwords on a regular basis would have nothing at all to do with improving on the "adequacy" of the "current" password (of this we would have to agree based on point 1 above).
3) so then is there a valid reason to change passwords regularly based on the conclusions we've reached above - it would appear there is NOT a valid reason to change passwords if in-fact we assume at all times the goal in every case for all passwords is to be using as fully adequate a password as possible at all times (hence, before the change and after the change this aspect regarding adequacy does not change). So, in other words, the password in use has been originally entered as an "optimum" password in regards to "security" (our goal in every case we utilize a password) - so a "different" password would not improve on "security" based on the premise as presented here in as much as that being "different" has no additional impact on "security" in-and-of-itself.

Conclusion (point): the probability of hacking a fully adequate password as possible does not change as a result of changing a password that is equally fully adequate as possible. Random combinations of input to hack an equally fully adequate password remains the same probability before and after the change simply because the adequacy remains the same in any case (upon simply changing a password).

So the conclusion in regards to our present day "madness" we deal with based on deductive logic and I might add simple "common sense" (rational premises as stated in place) is that changing passwords does not serve any purpose of any kind in regards to improving levels of "security" it would appear (assuming we at all times take the responsibility of using as fully an adequate password as possible - of which in that case, a different password at the same level of adequacy remains the same level of "security" in any case).

Has anyone else contemplated the "fallacy" that exists regarding the "concept" of changing passwords to (presumably) optimize "security"?
===============================================================================================================================

Now, here's an example of not only "madness" (that we ALL for the most part sadly practice in general) - but flat out "stupidity" in the example below (and keep in mind we're talking about a top level major bank w/ assets in the multiple billions of US dollars).

I was required to change passwords with a bank recently.
Why - because the bank added "special characters" as a requirement for passwords.
Why would a bank do this - presumably to improve "security" - right?
OK so this is what the bank did:
1) added "special characters" as a requirement.
2) dropped the requirement of needing an upper-case character however. (so passwords no longer required this [upper-case], hence all characters could be all lower-case. I can be sure of this because I will NEVER use an upper-case character unless I have to because it is "required" and my old password was using an upper-case character).

So I added a special character and at the same time used all lower-case characters (since I at that point could, in as much as upper-case was no longer required) of which I always do if allowed to do so.

What's the problem here in regards to not only logic - but just simple "common sense" (you might ask)?

Question - How many special Characters are there (i.e. "commonly used")? - answer: somewhere around 9-10 let's say (i.e. @,#,$,%,^,&,*,/,?... - that's generally about it...)
Question - How many letters in the (English) alphabet? - answer: 27 26.
So what the bank did was add 9 characters (special) and dropped 27 26 (possible) characters (uppercase alphabet) that can be used in passwords - a total loss 18 possible combinations of characters (which is huge, when considering the possible combinations that can be used by including this many upper-case characters).
Question - is that an improvement in "security" (a loss of 18 17 potential combinations of characters that can be used? - of course not!
So the requirement for users to go to the trouble of changing passwords to comply with the banks new password requirements is clearly to (by a very large magnitude) potentially lowering the "security" of passwords in a very significant way.

Just one example of the "madness" we put up with today.

Just thought I'd throw this out there (yet another example below) as far as my most recent "madness session" (on the phone) with a very large bank - i.e. in this case JPMorgan Chase Bank.

Recently after going through the steps to get a "code" to provide the bank to verify me as a valid customer the following occurs:
1) "Code" retrieved and provided to the website dialog page to confirm my identity as a customer.
2) After doing the above I get another page (paraphrase) stating: "Thanks for the information - we need just a little more information which consists of providing a confirmation "code" (right after I just finished supplying a "code") - which I personally get about 80-90% of the time. In this case, I am requested to call a number that happens to be "Customer Service". I find that about half the time "Customer Service" has no idea why I'm calling for a "code" the other half the time the agent knows the procedure to provide me with another code (albeit, this is not what is supposed to happen, as mentioned in more detail below).
3) I decided to take the time to discuss this with a "Supervisor" and was told that the "new" procedure with providing a "code" has "not been perfected" yet. Wow! - so a major bank releases code that "has not been perfected" (his exact words). I told him back in the day when I used to program for banks - if our software staff released to the public "code that was still not fully functional" - we'd no longer have a job real quick which reflects on the current "slack" attitude of most enterprises today who very often do similar things as reference here.

It appears banks are slowly taking on the attitude of Microsoft - to "beta" test software with the public (we all know how often MS will release a version that conflicts or creates issues that customers have to end up reporting back to MS - an example of long-term "madness" I speak of....).

Just to discuss "security" in a little more detail - it is not any longer uncommon for users to end up experiencing as many as 3 levels of security quite often now days, such as: 1) Check box to assure a "robot" is not in the mix, 2) coordinating icons according to instructions, 3) entering obscured text and then of course the now more and more prevalent 4) requirement to provide a "code" to confirm the user. I have personally, had in a number of cases a site using 2 of the first 3 examples along with then requiring a "code" in the end as well - hence 3 levels of security in many cases. We're at a time where it is the way of most enterprises today to keep on adding layer after layer of "security" one-on-top-of-another all of which needs to remain compatible with each other (successfully "handshake" between each "security" method used). And with that in mind, I can't count the number of times that "glitches" or in some cases complete breakdowns of the process occurs ultimately resulting in the user suffering the consequences of not being able to utilize what all this "security" is intended to "protect" in the first place.

I contend if a multiplicity of layers of "security" requirements are increasingly imposed on users results in a higher frequencies of failure points - what are we accomplishing in this case?... or better put, is all of this "security" worth it if very often the user (that is supposed be be "protected") in so many cases can't even accomplish what the "security" is supposed to be protecting in the first place?... (a question, that obviously led me to posting this topic)

Boy Howdy (oh my), what a really weird world we live in today!!! (imho)...and in this case, this specific "weirdness" is confined to the "technical" aspects of our lives which one would argue should not at all be joining in with the "weirdness" of "today's" world.

EDIT: Updated to reflect an accurate number of English language characters (26, not 27 - I bothered to count them this time subsequent to a later post)

[suzyne]

I think the issue about being asked to change what is already a suitably complex and secure password is that sites do not know that your password is so strong because the original is never stored, and they cannot know who is (and more importantly who isn't) using such a high-quality password.

Asking users to change their password is precautionary because sites do get hacked, and lists of active passwords do get leaked.

Sure, it's an inconvenience for everybody who is already using strong, unique and random passwords on every account. But to call it madness is a stretch when the intention is to protect the accounts of those who are not so diligent with their password selection.

[Pallid Planetoid]

I think the issue about being asked to change what is already a suitably complex and secure password is that sites do not know that your password is so strong because the original is never stored, and they cannot know who is (and more importantly who isn't) using such a high-quality password.

The premise used is presuming the password is already (originally) optimally secure - absent this premise - my conclusions do not then apply.

Asking users to change their password is precautionary because sites do get hacked, and lists of active passwords do get leaked.

To some extent a very valid point (considering that I was perhaps focusing more on random password generating software as opposed to a hacking events, that should be directly dealt with by "security" software), however the timing of these kinds of events (i.e. "hacking" of data) are totally arbitrary - hence a "hack" involving passwords could theoretically occur immediately after a password change was just done - hence the password change in-and-of-itself may or may not be much of a factor if any. My focus was on the "fallacious" concept to change passwords based on the concept that the longer a password remains the same over time as a reason for the change, beyond this - I concede your point is a totally valid one.

Sure, it's an inconvenience for everybody who is already using strong, unique and random passwords on every account. But to call it madness is a stretch when the intention is to protect the accounts of those who are not so diligent with their password selection.

The "madness" I speak of is in regards to the entirety of the extent to which multiple levels of "security" continue to grow out-of-hand from my perspective (and to the degree that failure points increase as those levels of security continue to grow, based on my personal experience).

[Moonchild]

Just as a brief primer on password/account security, there are several different factors involved:

1. Length of the password
2. Complexity of the password
3. "Guessability" of the password (dictionary attacks, etc.)
4. Infrastructure security (i.e. security surrounding account databases)
5. Log-in method security (e.g. captchas)
6. Multi-factor authentication

Points 1, 2 and 3 are guards against being able to brute-force crack the password, where 1 is more effective than 2.
Point 4 is critical in hackers being able to compromise passwords because if they can get a dump of the account database, any password cracking can be done locally.
Point 5 is useful for preventing bots from trying to probe servers for either stolen or cracked passwords, or for brute-force "live" guessing.
Point 6, if done properly will prevent account compromise even if a password or user's device is compromised. e.g. a code sent to your phone to confirm a password log-in is a decent second-factor.

Changing passwords on a regular basis is important to avoid databases taken from a breach of infrastructure from being useful (quite often these databases are old or errant copies, old backups, or what not) as the age of the database becomes very important in that case. Too old? -> useless. Even if your password is presumed optimally secure at the start, this stays applicable.

As pointed out though: passwords are not stored in plain text/reversible in account databases (if the system is designed with any form of security in mind, anyway), so the bank (operator-side) cannot assume original passwords are optimally secure and must assume therefore they are not, and apply this policy to every user.

[adoxa]

Question - How many letters in the (English) alphabet? - answer: 27.

Wow, have American and British English diverged that much?

[Pallid Planetoid]

^ @ Moonchild, all very valuable info to know, for sure ... hence much appreciated (of which I'd add is for the most part new to me personally).

... that said, based on my premise (as formerly stated) that a user is assumed to have applied a password that is what is considered to be "optimal" based on the applicable limits imposed at the time by the "standing" credential "rules" as to what can be used during the interim the credential "rules" continue to remain static (unchanged); I continue to stand by my conclusion that a password changed under this defined (limited) scenario will not result in any meaningful advantage over what would be the current password in use during the period of time the conditions as defined remain in effect.

On the other hand, at a point where credential "rules" might happen to change then a password update my or may not in-fact be warranted in regards to improving "security" that would however depend upon to what extent the "new" credentials "rule" changes serves this purpose at that time (rules that provide for additional combination options would be warranted, however regarding the credential "rule" changes that applied to my example discussed in my previous post would not likely provide any improvement in security at all -- simply because the combinations of options allowed became more limited in my example thus my reference to "stupidity" as opposed to "madness").

In conclusion: absent any "rule" changes, as I see it, there is little to no advantage in changing what is an already "optimized" password according to the standing (static) credential rules as they apply, as opposed to the event where credential "rules" do in-fact change at which time it then depends upon the extent of credential "rule" changes as to whether an update might translate to improved security.

So to my overall point in all of this is that the "standard" approach by most in regards to maintaining "secure login credentials" is to change passwords on a regular basis regardless of whether any credential changes have occurred - my point in regards to this "standard" within the confines of my scenario is that absent any advantage that might result in credential "rule" changes and assuming the password has been "optimized" according to the standing (static/unchanged) "rules" as they apply -- this long held "approach" is virtually nonsensical for the most part, imho.

[Pallid Planetoid]

Question - How many letters in the (English) alphabet? - answer: 27.

Wow, have American and British English diverged that much?

Uh, my bad - I bothered to count them this time, there are actually 26 letters in the English alphabet (at least as far as what I was taught - so corrected my original post as such) So (you got my curiosity up), how many letters are there in "'British English" pray tell?

[Moonchild]

In conclusion: absent any "rule" changes, as I see it, there is little to no advantage in changing what is an already "optimized" password according to the standing (static) credential rules as they apply, as opposed to the event where credential "rules" do in-fact change at which time it then depends upon the extent of credential "rule" changes as to whether an update might translate to improved security.

Seen in isolation you would be correct, but that's not the reality.
The reality is that you are dealing with a large group of users, users will not choose optimal (including unguessable from context, etc.), unique-for-the-site passwords, and database/infrastructure breaches do happen. It is important to err on the side of caution as a result and take steps to avoid the risks I pointed out. My remark "Changing passwords on a regular basis is important to..." remains valid in that context. You are not just dealing with your choice of password in isolation, but also with the server-side and general external factors that may leak long-use credentials.

There are solutions for this of course. (True) multi-factor authentication is one, PKI (with extremely strict guarding of private key security, as well as key passwords) is another. Most sites are choosing the former these days. But passwords are of variable robustness by their nature of being chosen by a human brain, and need to be treated as such. As stated: providers cannot assume original passwords are optimally secure and must assume therefore they are not, and must apply this policy to every user.