Security is a complex concept. Sometimes things that feel "intuitively right" are not in the best interest of securing your access.
Quite often, we are secured FROM accessing the services we so desire...then we resort to the oldest and least secure SMTP protocol that is long overdue for Rev.3 or Rev.4.
Many have adapted the use of "password manager" tools / addons.
Let's consider if there is a better alternative to existing solutions.
In few example cases, I will show how "feel-good" solutions, that are often "specifically designed" to improve your security, will actually decrease security of your access or even open ill-considered backdoors into your systems.
Case 1. ID Federation vs Multiple ID
Imagine controlling several separate security domains.
This happens most often at work, where you use one ID to logon to your PC, then another one to connect to your (Development Environemt/Model Environment/External VPN/Internal Applications etc).
You may have another username (a).
You may have to use slightly different usernames (b).
Sometimes you use exactly same username (c).
What IS important is you do not care to use different passwords in each domain. You would go crazy if you did, especially in case (c).
"Domain Name" is often not considered by the Application developers, and users are not always aware to which domain they are logging into.
Sometimes domain name is not even shown, especially in cases where applications are not designed for, and hence would not allow cross-domain logins.
What IS ALSO important is that there is no easy way to make sure users use different passwords in every domain.
Your SAP solution would not check Active Directory and make sure you use a different password.
Where are we ending with this non-SSO enviroment?
Users like to use same passwords everywhere.
It is enough to hack one enviroment and then reuse same password in other environments.
The thinking that non-SSO environment would "protect" against a password compromise is not often substantiated in practice; it is "false intiution".
How easy it is to protect against potential compromise?
We'd have to make users change passwords in every domain.
They may not even remember all passwords, when some were left behind and unused!
When disaster strikes, many doors will be open even though the storm is already gone.
When people leave the company, several non-integrated systems may still contain active credentials.
This is especially bad for VPN or other internet-exposed systems that are not AD-integrated.
What's the best architecture for multiple domains controlled by same people?
Use full SSO, one login connects users to all services at work.
Through IT Policies, make sure that every app deployed supports a form of integration with your most important credential data, Active Directory.
Prefer Kerberos integration over LDAP. LDAP would not support multi-domain environment easily.
Let application developers, modelling and vendors build a one-way external trusts towards your single forest root domain.
This is often safer, and is always cheaper that external "integrations".
Additional advice - use AD as your master DB. If you use external ID providers (Oracle, IBM) then those must have admin service accounts into your Production AD. This is bad...
External vendors (or their subbies) may be able to reset passwords of your CxO and read their email / access documents. Again, those service passwords most likely will be moved around the world over unsecured SMTP emails, often on "Cloud" providers and multiple governments looking over the shoulder.
Instead: Let your forest root domain controllers keep all IDs safe and ready to be reused in your forest child domains. Let DC talk to DC to automatically reset computer account passwords at predetermined intervals. No humans mucking around.
Case 2. Policing the passwords.
In password credential management, there's a number of parameters that often make even "experienced" people make stupid mistakes.
Every time, the whole password lifecycle process must be considered in an end-to-end manner.
The basic password policy parameters include:
- minimum password length
- maximum password age
- minimum password age
- password history
- password complexity checks
- password change warning period
Many of those parameters require consideration of how your passwords are: set initially; distributed to users; reset by users; reset by service personnel; aged and requested change; accounts disabled etc.
Let's take a quick example of CONTOSO company.
They have set password history to 24, and password minimum age to 1 day.
When passwords are reset by the helpdesk personnel, they are dictated over the phone to users calling in for a password reset.
Issues? Oh yes!
Firstly, when dictated over the phone, several users in the call centres (sometimes abroad) get to hear them out, spelled clearly and nicely.
Secondly, the two parameters they set, were designed to prevent the same specific unsecure situation - users recycling same passwords indefinitely.
But because these parameters designed to reach the goal via different means, only one or the other of them should have been used.
Using both, while seeming to "improve security", simply by tweaking all the knobs we see there, in fact cause a very insecure situation.
Password History is a barrier for users to always select a new password when changing it. The depth of password history log defines how many passwords user have to invent, before reusing the old and loved one.
Set it to 1 and users only have to change it twice - first time to invent a new password (the current one goes into the history log) and then back to the second password. Two passwords can be recycled indefinitely.
Set it to 12 however, and I doubt the users will go through the pain of changing passwords 13 times (inventing new ones) in order to reuse their favourite mot-de-passe.
In case of CONTOSO, however, the minimum password age was set to 1. This parameter was designed for cases with no password history.
Users would have to WAIT AND USE the new password they just set or got assigned BEFORE they could ever change it again.
This means that all newly assigned passwords, that were probably overheard on both sides of the phone calls, cannot be changed immediately by the user.
It also means that if someone overlooked your password as you were changing it, you'd not be able to change it once more when that person leaves the room.
They would have to use the passwords as assigned at least for one day. Compromised new passwords stay compromised for at least 24h. Not good...
What this means in practice is that passwords reset by the service desk are never changed by the users. Not on the next day.
Never - until the next expiration cycle.
There is no way to force users doing that.
The only way out is to change the policy and set minimum age to 0 and check "Must change password at next logon".
The password history will take care of "inventive" users trying to revert back to old and loved passwords.
As of now, users tend to stick with very simple and possibly compromised passwords well beyond the first day.
As for the password expiration period, it should not be left at default 14 days. In 14 days, many users are reluctant to change passwords so far ahead of time.
At the same time, 3 days is a bit too short - users may be compelled to change it on Friday and they won't remember the password Monday.
Five days seems the best choice. Users who receive the warning on Monday will have full week to think about doing it. They'd know they need to do it "this week".
It the pesky dialog pops up Friday for the first time, 5 days is good time to postpone it "till next week".
Password complexity? Of course.
If you serious about complexity, you should write your own PASSFILT.DLL.
Include dictionary lookups, as well as proper non-generic error messages towards users, so they know why the new password they tried to choose was a poor choice.
Case 3. External domains
Consider your "work" environment is fine-tuned and well-considered, time-tested and pen-analyzed.
How can you be sure your users are not using same password on their Facebook?
Well, this is where our discussion will lead us to the next gen of ID management, the frontiers of developments ongoing in various bodies and corporations.
Remember Microsoft CardSpace?
This was Microsoft's first attempt at "embracing and extending" credential management on the websites, "out there".
By design, web developers would have to include CardSpace support in their websites.
Then, once users connected to the website, it would send a signal to Internet Explorer to indicated that it accepts CardSpace.
Come on, fire up your XP machine and check in Control Panel.
It was basically same as Windows Credentials Manager (still present in Windows 7 and 8) - only for websites.
You could fill up, save and one-click-reuse so called "cards", one per site. Each card could contain your names, email, as well as "salted association ID" that would be used in place of password on the particular site that generated and saved the card.
Now consider the SmartCard standards.
Many computers still have the readers. But it has been a long time since I saw someone use a smartcard. OK CBA folks I know you do :)
The real reason why smartcards aren't popular is because the current standard sucks.
It does - because it hosts only one certificate. It seems designed only for "work use".
One certificate, same thumbprint - very easy to track the user.
This is definitely not a good architecture - for privacy reasons.
There's also no controls designed around what sites can access which certificates.
A better architecture would see the SmartCard standard extended and merged with some concepts of the Microsoft CardSpace component.
1. From a hardware perspective, each SmartCard would need to be able to keep up to 1024 user certificates (or other credentials), one in each separate isolated cell.
2. Each cell would be signed by a special website certificate, and verified via full DNS name. Other sites would not be able to send requests for that particular card.
3. One per-card PIN would unlock all cells, but each individual user card request would be screened by OS UI and approved/denied by the user.
4. OS would support new card creation by suggesting values from the user profile (name, nickname, email etc) but the user would have the right to override all values to establish a new account with a new service.
5. Some government sites would only accept "verified" cards that were issued by specific government sites/bodies.
6. Cards would not be "locked" to specific countries, they would be open for any new web services globally.
7. It would be possible to combine multiple "government verified IDs" on one card.
8. During new account creation, a uniquely-generated credentials would be stored on the card, only accessible by the site that generated it.
9. Some websites would offer to reuse government IDs, while allowing to create a new "local" account to anyone.
10. Optionally, a plain-text password can be displayed on the screen, to be taken by the user and used on computers without the new smart card readers.
With inception of such universal standard, all woes about passwords would be solved and the internet would become a more secure space.
It is time to move away from insecurities of keyboard keystrokes into the area of specialized chips and certificates controlled by the openly reviewed and secured hardware/OS standard.
Instead of building ID around Facebook, it's time to ask for universal standards for the new generation.
Ask your local Member of Parliament to support this.
Share and repost in social media!
Help to propel the cause to get rid of password headache and insecurities.
Chime in the comments as well - do you develop something like this?
Can you help developing this?
