Tuesday, June 24, 2014

Disparate identities? No thanks.

We all are used (or at least adapted) to keep and reenter a multitude of passwords.

They follow us everywhere - at work, when home, even when we're calling the bank on the go.

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?

Desktop Peek guffaw

Dear Reader
just a little tip for those who are annoyed by the “hide all windows” feature automatically activated when you [accidentally] move your mouse into the lower right corner.

It is easy to disable this, just by right-clicking the small empty bar in your lower right corner
and un-ticking the “Peek at Desktop” option:


Left-clicking the bar will still show Desktop.
At least it’s not activated accidentally.

Wednesday, April 23, 2014

NSLOOKUP prank

If you name your server "EXIT", people won't be able to troubleshoot its name resolution using NSLOOKUP.

Tuesday, April 8, 2014

Microsoft and Vendors

PC hardware vendors should only hate Microsoft for removing "Computer" icon from Desktop by default in Windows 7.
"Less-hardware-minded users aren't keen to upgrade often..."
NB. The Recycle Bin is holding on.

Life is Good

That's it, folks.
I now only have time to write quick tweets here, not full articles.
I hope you will like more frequent but shorter messages.
They will still contain same kind of insight, just packed more densely.
Life is Good.

Thursday, August 8, 2013

Built-in tracking protection in IE10+

A simple trick to help you thwart attempts to track you on the web.

It's a little-known built-in feature that applies to Internet Explorer 10 and later users; yes, you should update any prior versions you may still have, even if you do not use IE - many system components are using its frames.

While in Internet Explorer, press Alt-X or click the Tools button on the toolbar (most right), select "Manage Add-Ons".

Click "Tracking Protection" on the left - you will see a pre-defined "Your Personalized List" on the right.

Click the list and then click "Enable" button below.

Click "Settings" button below and select "Automatically Block" on the dialog that opens.

"OK", "Close"


Now what happens is IE will detect tracking frames on all websites that you visit.
If there are more than 10 occurences (different sites) having embedded the same tracking scripts, it will be considered a tracking network and will be blocked from placing an identifying cookies on you.

Hopefully this helps stopping the trackers "profiling" you, i.e. gathering info on types of sites you visit, and placing you into certain categories.

Possible uses of tracking involve targeted advertisement, market research for correlated traffic, audience statistics etc.

Not bad for an un-advertised feature that is given for free to all.

Tuesday, August 6, 2013

Lost in phone, or another opportunity for iOS 7

Let me confess, I have been using Apple iPhone since 2008.
Back in 2010, my phone was stolen. A month later, we were moving to Australia and I did not buy a new one.

I have been using a Nokia phone for a year, it was a Symbian one.
Interestingly, I did not miss the iPhone. I was on the lookout for something new, something better.
It happened to be an hp pre3 powered by [ex Palm's] webOS operating system. But that's another story.

I tried to understand why I did not miss the iPhone, after all, I was a Mac user since 2001.
And I think I can explain why, at least to myself.

There are things in iPhone experience that simply make you bored.
The same old grid of same old icons, mostly static. Onerous App Switching functionality.

But now I also see things that actually enrage me, even if they used to do it subconsciously.

Let us talk about one.

Phones are many things to us now, but for me, they still must serve well as PHONES.

It seems that iPhone fell short on this, even compared to my first smartphone that I bought in 2004, the absolute flagman of the years and everything before the iPhone - Sony Ericsson P910i.

Consider unlocking your iPhone, you will see Phone and Contacts icons.
Inside the Phone icon, you will see Contacts tab.
Along the Phone app tabs, you will see "Favorites", "Recents", "Contacts".
As well as "Contacts" outside of the phone app, on the dock.
"Recents" tab is split in "All" and "Missed" categories.
Can you still follow me? :)

Guess what? THERE IS NO PEOPLE PHOTOS, NO USERPICS not in any of these multiple tabs. Huh?
All four tabs I have listed, have no people faces on them. Not even in Favorites!
To see a picture, you need to drill down to a particular contact! This is in 2013.

Many times we are trying to catch up with people on the go, while walking, some [unwise folks] even when driving.
No pictures does not help at all!
What is even worse, is getting stuck in "Recents"-"Missed" and trying to dial a number who you just talked to and said "I'll call you in a minute".

This is because Phone app remembers where you were last time, making navigation to where you want to be this time a process that takes more brain cells to coordinate their work, distracting from other things you're trying to do (unless you're sitting on a sofa playing the phone).

I took out my old SonyEricsson and checked the Phone application.

Always takes you to Favorites that have faces on them. Two-touch calls to Favorites are possible from wherever I am.


On the iPhone, if your favorite people are calling you then your Recents will look much like Favorites, but sometimes sans the guy you want to talk to now. Same-looking text in both tabs, no pictures. Frustration. No wonder they need Siri to help.

Finding yourself switching to less-often used tabs like Dialpad is OK.
Having to switch out of that rarely used functionality is not.

Another source of confusion is the double Contacts functionality.
Since there are two of the Contacts tab, and each remembers its own position, you will have to re-find (find again) the user that you have focused on, should you go to the "wrong" Contacts tab.

It took me some time to realize that in order to send an email, I have to touch the actual email address instead of reading all the button labels below in vain search for "Email" button, then trying to figure out whether "Send Message" button meant "email message".

There's simply not enough visual cues. Have a look at how it was done in the SonyEricsson.

One more thing about my ancient but greatly usable phone.
It seems to be the only 3rd party phone that Apple has written software for.


No kidding, Apple programmed for Symbian UIQ 2.1. Steve must have cared enough.
Here's a proof.

The iSync agent worked hand-in-hand with iSync Apple app for MacOS, making sure that bluetooth synchronization of Calendar, Contacts and such was impeccable. And it was, unlike my Nokia PC Suite experience.





Overall, with a couple of tweaks I hope that Apple will resolve these issues in upcoming iOS 7 - they just need more of that "attention to detail".
But maybe not - it does not seem to be about phone calls anymore...at least, this is not Apple's business.
Or is it?