password policy change

[pribis]

Ok, so suddenly the passwords I use to use aren't working. I'm told they are too weak and need a special char or number? My passwords eight characters and contain upper and lower case and a number and are never based off of regular english words. So they are strong enough for an inhouse system. I tried just adding another number, but nope. I had to actually add a ~ to get it to let me save.

Did the default password policy get changed?!!

[shanec]

That is correct, we have been slowly rolling out enhanced security policies to better meet government standards and auditing requirements. We have also seen an uptick in issues relating to some poor password policies as even some random person on the internet can often make a correct guess or more commonly is that a typo allows one employee to login as another. That being said the new password policies only apply to new hires at this point and passwords with upper case letters and numbers should work though you may need more than just one number and one upper case character for it to be secure enough.

[pribis]

Our passwords are secure and frankly screwing with the password policy sucks when we already have a company wide one that isn't in sync with yours. So now I have to change our policy to fit yours? If you are going to do that then please enable the password policy editor for the community edition. What you are in effect saying is either buy the pro or we will mess with the policy so you have to use the pro edition. That is just plain frustrating. Between this and ldap (lack of TLS) issue, I'm slowly being forced to consider branching timetrex for our company's use. Something I'm loathed to do, but you are seriously making things very difficult when it comes to using tt in a cooperate environment with multiple application sign-ins.

Also, now users are required to change their password on login? How do I shut that off. PLEASE tell me I can shut that off.

(p.s., I am frustrated, but I do love this program. Except for these couple issues I am very appreciative of the work you've done).

[shaunw]

The password policy you are running into is the minimum requirements for a password, even if you upgraded to the Professional Edition, it would just allow you to control some additional password policy settings or make the passwords required to be even more secure. Therefore your conspiracy theory of this being some evil master plan to force people to the Professional Edition doesn't hold water.

Continuing to allow poor passwords has negatively affected TimeTrex is several ways, including users complaining that it is "insecure" because they were able to login in as someone else. (Caused by having common usernames and extremely poor passwords) Of course it is not true that TimeTrex itself is insecure, but it did allow users to set insecure passwords. Its clear that users will not use secure passwords on their own so our hand has been forced to require it instead.

Having said all of that, we do not consider the password policy itself is not overly burdensome, in fact this password will be accepted:

abcd123

However this password will not be accepted, but it is right on the threshold:

Abcdef1

Adding one more character, or number would allow it to be accepted, ie:

Abcdefg1

Unfortunately there is no universally standard way of calculating password strength, so everyone does it slightly differently.

This is a interesting website that will give you an idea of how secure your password really is: https://howsecureismypassword.net/

[pribis]

Thanks for the feedback. I guess the problem I'm running into is that you and I have different ideas of what is needed for the environment I work in. Besides, passwords that are so difficult that they cannot be memorized with a certain amount of ease just get written down and stored out in the open anyway (which may happen no matter what is used, but the likely hood of that happen definitely increase with pw difficulty). If it were up to me I would use passwords that are fairly long and very complex. In fact, I do for personal accounts, but I have the benefit of a pw manager. Employees here do not.

I'll just have to deal with it. But truly, finding this out after I upgraded was really bad. I've disabled it in the code for now while I think about how to best handle this.

Anyway, you didn't answer my last question: is there a way to disable forcing users to change pw on first-time sign-in? Or do I have to do that myself too?

Again, thanks.

[pribis]

Concerning your passwords that would or would not be accepted.

I went back and checked that out. You are right (of course), but it seems that maybe some tuning would be a good thing.

Like why in the world would abc123 be accepted but Paumiu6w or Deis7iLi not? Sequential numbers and letters are typically considered really bad. In fact, that site you recommended to test the pw lists that one as crackable "instantly". 15 hours isn't that grand either, but again, not worried about that in our enviro.

So I'm going to have tt enforce a password policy that makes my job much more difficult but the user can circumvent?

Whatever, obviously not much I'm going to be able to do about (besides what I've already done). But figured I'd mention it.

Out of curiosity, if I use LDAP only authentication, how does it handle users being required to change their pw at first login? Does it not do that when ldap only auth is enabled?

Thanks

[pribis]

One more thing (is this written down somewhere? I looked in the manual but didn't see it):

Does the password policy expire passwords? I don't want to be surprised by this one either.

Thanks

[shaunw]

There is no setting to disable forcing employees to change their password on first login. Anytime a password has been "compromised" (ie: someone else knows it, either by manually setting it for the employee or using the forgot password to reset it), TimeTrex will force the employee to change it.

TimeTrex can't change passwords when using LDAP authentication, so that functionality is disabled.