maandag 19 november 2012

I shared an email with you

Twitter introduced an interesting new feature, emailing a tweet that you think might be of interest to someone else. Twitter lets you send an email straight from the Twitter web interface. If you choose so, up pops a browser window that lets you enter the email address of the recipient and enter some text next to the tweet. Press a button and Twitter takes care of sending the tweet.

Why does this bother me?
Some time ago I wrote a blog entry about Behavior centric identity management. I said that my Identity is constructed using several components, one of which is my behavior. You may know my name, or my interests, my relations, my work, whatever, but the more aspects of me you know, the better you know the real me, the closer you come to the real me. In order to be in control of the real me, for me this means seperating these components as much as possible. That's why I use netvibes rss aggregator (that knows about my areas of interest) instead of iGoogle (that will disappear anyway).

My Twitter handle is one of my identity components, just like my email relations. And the tweeps I follow are not randomly chosen, no, they are part of my identity too. But Twitter is just an instrument for me to use and Twitter has got nothing to do with my other identity components.

But now that they started offering an email facility, they have to possibility to combine my separate identity components. They can combine my areas of interest (the tweet that I want to share) and my non-Twitter relations (this function is obviously meant to reach non.tweeps, otherwise a simple RT would do). It's an effective interest aggregator.  The email sent contains lots of information, but most important is that Twitter owns the mail server. And Twitter is the owner of the sent email message.

Twitter could of course offer the email button and start my email client, just as easy, and they would never know to whom I would like to send a tweet. But by implementing the email facility like they did, they are in the middle of my communication channel with a non-Tweep. They know that my Twitter ID is interested in informing a non Twitter identity about a certain subject.

Since Twitter is becoming the on-line memory for our thoughts, I don't think that Twitter will remove all emails and temp files, do you?

maandag 8 oktober 2012

Confirmation e-mail shows password vulnerability

This week it happened again: I received an e-mail with a confirmation of creating an account for a webshop. Yes, it is very comforting to know that you have an account. But apart from the fact that I created yet another account somewhere in the cloud, I noticed that the email showed my account credentials in full text. Reading my accountname was not that special, but seeing the password I entered on the site was less reassuring.
If the mailserver sends an email with a readable password it means that my password is accessible for the mailserver in a readable format. And that means that the password is unencrypted somewhere between the website and the mailserver. In most cases a content management system (with a user database) or a webshop system (with some kind of CRM database) are familiair with my account. And both these systems use the emailserver to inform me about all transactions. Including account creation. The same can happen if you click a link to the forgotten password function. Some systems resend you the password for your account. So they must be able to read the password from your account in the database.
For me this implies that the CMS and/or CRM system do not store the password in encrypted form, otherwise how can the mailserver get the content for the email? I don't suppose these systems use a brute-force attack to discover your password...

In this case I informed the webshop owner that I suspect that there is a vulnerability in the user management function. 

Best practices:
  • Use third party identities (Oauth, OpenID etc.) to create customer accounts, that way you don't store passwords;
  • Use a hashing function for passwords in the database (and please pick a secure algorithm);
  • If your CMS or CRM doesn't support encryption of passwords, change to a secure system.
And never ever send an email with the password in readable form. Better send an email with a link to the password reset function.

If you encounter sites that email your password (either at create time or at password reset), please inform the webmaster of this vulnerability.

donderdag 27 september 2012

Identity Management and CRM

The use of digital identities for internet users has been discussed in many places. And plenty solutions have been developed. There are lots of identity providers that offer (open) standards based digital identities that can be reused.
For companies the use of digital identities is only part of the problem, the use of external identities is just becoming a necessity.

Apart from offering access for external identities, organisations also have to cope with the internal identities of their customers. The more (legacy) backoffice systems organisations use, the more difficulty they have in identifying the value of their customers. Nothing new here: this problem is solved in Customer Relation Management (CRM) and Master Data Management (MDM): we create a 'Golden Record', a unique internal representation of a customer, that is related to all coupled internal backend systems.

Master Data Management is an area with specific problems. How do you connect customer accounts in different backend systems with different identifiers. Backend1 customer A1 can be the same as Backend2 customer R2D2 and may not at all be Backend3 customer A1, but ASDFG9 instead. Master Data Management uses intelligent rules engines to connect Id's and knows some trics, like deduplication. I will not go into detail (I don't know this kind of process well enough).

In a sense both identity related problems look alike, although they are mirrored. Let me show it in a simple picture and await your reactions...:

dinsdag 25 september 2012

Your Twitter ID as a source for Twitter spam

I'm getting more and more spam in my Twitter timeline or in my twitter direct message mailbox. And these tweets come from my own twitter friends. And I'm not alone in this. Many others mention this as well.
Tweets like this: “GET MORE FOLLOWERS MY BEST FRIENDS? I WILL FOLLOW YOU BACK IF YOU FOLLOW ME” or direct messages like “lol ur famous now [link]” will in most cases link to malware infected sites.
And now and then a twitter friend reports that his twitter account was hacked.

I don't believe that this is the case. Accounts don't get hacked easily. Of course a pc could be infected with malware, with keyboard sniffers and password stealers, but apart from that, hacking an account is not that easy. Proof? Even security professionals became the source of twitter spam messages.

If your account was not hacked, how can this spam flood happen?
Tweets defininately come from a trusted person. But since there is no way that you can create a tweet with a faked sender address, these spam messages really come from your friends.
On his blog (http://nakedsecurity.sophos.com/2011/06/23/beware-shortcuts-for-getting-more-followers-on-twitter/) Graham Cluley from Sophos explains how these tweets happen. These tweets come from services that you(!) allowed access your twitter account. And these services may well do other things than you wanted them to.
Twitter can be used as an identity provider. It uses the underlying oauth protocol to authenticate twitter users for different services on the internet. And this feature is not only available on pc's but also on mobile phones. Very practical: if you use your twitter account you don't have to login using a user name and a password. All that is required is that you tell twitter to allow access for the external service. And in fact you allow the external service to post messages on your behalf.
Through this link ( https://twitter.com/settings/applications ) you can check what apps you trust to post on your behalf.

Do you really trust all these apps? My advise: You better revoke all unknown or unused apps. And btw: if I receive a strange tweet from your twitter account, I will use a second channel (like LinkedIn, or mail) to advise you to clean your twitter trusted app list.

dinsdag 26 juni 2012

Let's kill the IAM acronym!

In the information security industry, the IAM acronym is well known, it's the acronym for Identity and Access Management. IAM is used in blogs and tweets, consultants manage IAM projects and vendors sell IAM tools and suites. But I am feeling less and less at home with this acronym: it feels like a false acronym.
Identity Management (IDM) and Access Management do not exist together. These terms point to different processes and responsibilities. Let me explore and explain this some more.

Identity Management is a process for managing the lifecycle of identities within a trusted domain, be it a real or virtual organisation or an Internet resource like a mailserver. Identity Management is responsible for managing digital identities and user accounts. It is about 'who', it's a process for managing 'subjects'.

Access Control is a whole different ballgame. It's got nothing to do with 'who'. It's all about defining 'what' and 'why' for accessing 'objects'. Access Control is about defining the access policy for managed objects and resources. And it's about the person responsible for defining these policies. Access Control is a shared responsibility for a process owner, who in turn should define access rules for realising Seggregation of Duties, and a Data Owner, who is responsible for data governance and who should define access rules based on all kinds of laws and regulations.
The process owner and the data owner have to decide what kind of permissions should be available under what conditions. A process owner should not be interested in managing the accounts accessing his resources, but he should be interested in why accounts might be able to access his resources. And he must be interested in the audit trail: who did what.

Of course there is a link between the two processes. And that's simple because Who can do What and because of Why. The link is the digital identity, in most cases addressed as a Role of User Group.

Identity Management can largely be supported by tools. IDM is responsible for synchronising user accounts, roles/groups and passwords between systems and for provisioning attributes towards all kinds of related systems. The business case for IDM is in lowering costs. A single point of administration lowers operational costs and results in better data quality because of it. IDM can be implemented in an IT project.

Access Control is a business process. There's not a lot of technique in this process. Of course the rules have to be implemented in systems, but it's not an IT responsibility. The business case is not in lowering operational costs, but in delivering better transparancy and governance.

IAM projects tend to result in either an IDM implementation or in nothing at all. So why call it IAM after all? We better start calling it Identity Management and Access Control, or, as I tend to do, IDM/AC.

With the growing acceptance of Identity Management services in the cloud, separating IDM from AC is a logical consequence. The next step will probably be delivering Access Control in the cloud, in the form of Policy decision engines using SAML and XACML. And this process is better of by not managing Identities at the same time, so that it can be re-used regardles of the process that requires this kind of functionality.