Thursday, May 28, 2015

What is Zakintosh?

One of my pet peeves has long been information security.
Having worked and played with dozens of 'non-conventional' computer systems made me think about ways to MAKE SURE that a computer system can be trusted.
But what would it mean, and what needs to change in order to 'give way' for a new, secure-by-architecture, computer design?
What specific properties, business decisions, and ways of maintaining and supporting such a system would come to life?
I have worked on Zakintosh as my post-graduation thesis in Computer Science and I'm now ready to share it with you.
In my following post I will clarify all those and give you a good idea what the FUTURE of secure computing may entice.
You might even realize that some pieces of the puzzle have been put into place by some current actors.

For now, let's simply set the goals to be achieved by a hypothetical and highly theoretical 'Zakintosh'.
1. It must be secure from the user. Actions of software users cannot cause malfunction of system software or hardware.
2. At any time, the users can be sure that no clandestine (unrequested) operations are being performed by Zakintosh.
3. Software infection is not possible.
4. System is easily auditable. Status of system components and software can be checked by user, and can be trusted.
5. Third party security add-on software (Antivirus, Antimalware) is not required nor considered necessary.
6. The ultimate responsibility for system software security is with the system vendor.
7. There are no "trust levels" of computers like "FIPS-compliant" etc. The only high level of security is available to all Zakintosh users.
8. To compromise the system, hardware must be modified.
9. Hardware modifications to Zakintosh carry a legal penalty in many countries.

These are the basic premises around which more deductions will follow.
I am keen to share more of my vision in the next post; what do you think so far?

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


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.