Tuesday Dec 20, 2005

Identity, Security & Theft

In todays world, where we all talk so much about identity management, identity theft and security, we get blindsided by the framework that dictates the workflow. We all have our arguments and justifications of how identity management can enable security and also inadvertently lower the risk of identity theft.

Mark Dixon has a very nice post on identity problems. Sara Gates have a nicer one on "accelerate without fear", Robin Wilton has one on "identity fraud, not as we know it". All said and done, there's also the much talked about infocard, and Microsofts definitions of the "Laws Of Identity".

I was reading between Sara Gates response to Dave Kearns post on Identity Theft. when I stumbled on Kim Camerons post on "Identity Information Theft versus Identity Theft".

But hey !! hold on a second here... I just didnt get Dave's point... Dave goes on to say

Data breaches are a security concern, just as are stolen laptops (some of which hold identity data). But, so far, none have been shown to lead to identity fraud. There are few if any cases in which identity data was deliberately stolen in an online transaction.
in a post titled "How real is the threat of ID theft when holiday shopping online?" is he kidding by saying "There are few if any cases in which identity data was deliberately stolen in an online transaction"

Yes, The Holiday shopping period can be considered "approached" rather than "soon approaching". I have found myself shopping online like crazy... AND THEN !! I read Dave Mathews, report on "Man In The Middle Attack". Hey SSL is good and thats what I relied on all this while when I shopped online... SSL specifications were initially drafted by Netscape, & the Sun-Netscape Alliance released the PKI Library Source Code to the community on 2000. Microsoft adopted it too (someone correct me if i'm wrong here) and Internet Explorer was built to support HTTPS transport.

Well but after hearing the Dave Mathews, report on "Man In The Middle Attack", I am a bit reluctant to use Internet Explorer without being 100% sure of the security that the application itself provides me with.

So: Is Identity Theft all about ensuring the authenticity of the "user/consumer". What about the Applications and Sevice Providers and their authenticity ?. Should it not be a two way trust? I understand the fact that service providers need to ensure that the user is who he/she claims to be, but at the same time I believe that the user also needs to be able to trust the service provider and the transport layer in between. What IF I inadvertently provide my "valid" credentials to some I believe to be a service provider ? Well, it's the "Man In The Middle" that I'm worried about. Identity Management frameworks today are all about protecting the interests of the "service providers". But what about us the consumers? has anyone given a thought to that ?

Bill Gates had made an announcement about vintela being the Microsoft preferred vendor for extending Microsoft management technologies to Unix, Linux, and Macintosh systems. HEY !!! when Microsoft could not get a SSL implementations in Internet Explorer right, would I trust them to do "Identity Management" ? and that too with Active Directory as the backend ?

What IS clear is that Microsoft bought one of the first "metadirectory" companies (Zoomit) and is using their technology bits to build interfaces between Active Directory and the rest of the world.
HEY !! Didnt Kim Cameron come with it ::no offense Kim. ? (hint: remember: sun bought innosoft, and I believe that innosoft was also a forerunner in the "metadirectory" space.)

Didnt Kim Cameron propose the Identity Metasystem?

SO: Is the Identity Metasystem based on an Active Directory backbone and Internet Explorer Integration in mind ? (I'm not theorizing a conspiracy or anything here... I'm just thinking out loud)

WOW !! I'm already SO lost in my OWN POST.... (I need a technical writer to help me I guess...)

But however, my basic point is... WHO DO I TRUST ?


UPDATE :If I had the assurance that the service provider I was interfacing withg was using a SECURE COMPUTING structure and/or framework, I'd be more trusting of the vendor/service provider i'd deal with... (hint hint hint... see Sun's Suite Of Security Products...)

Tuesday Aug 30, 2005

Is your bank as secure as you would want it to be ?

Microsoft has been condemning, the practice of using NON SSL browsing methods, especially for online banking. However, Bank of America, Wachovia and Chase, as well as financial services giant American Express have decided to not concurr with this approach according to this report on NetCraft.

Netcraft's SSL Survey provides detailed information about encrypted transactions and e-commerce, including the growth rate for SSL-enabled sites, and which operating systems, server software and certificates are most widely used on these sites.

I had blogged about Secure Passwords last month, and had mentioned the usage of a Password Hasher using JavaScript. If these banks DO NOT want to have HTTPS enabled on their high traffic login pages, they could at least use the Password Hasher to encrypt the data sent back to the server.

I feel glad that this time I agree 100% with microsoft on their stance on SSL and NON SSL usage. Well, I also do understand the Bank's need for using NON-SSL for high volume traffic sites. But one should draw a line somewhere and not compromise the security of their customers Identity and credentials ! (and that too in this world of Identity Theft).

NOW, that's where they should be looking at Access Manager. If they let Access Manager broker their authentication requests, they could continue using HTTP for high traffic pages and then when the user tries to access his online banking information Access Manager could Authenticate them over HTTPS (ah! did I forget to mention that Access Manager authenticates using TOKENS and not TICKETS), and well, with the complexities of the policies and rulesets that Access Manager can handle, the server serving up "critical" information could all be served securely. Did I also forget to mention that we have a Secure Remote Access Gateway too?

Talk to these Banks Please...

Wednesday Aug 03, 2005

help yourselves from PHISHING ebay emails

Paul Mutton from netcraft has posted a nice warning to users about the emails that we receive from ebay.
Fraudsters have exploited a flaw in the eBay web site that allows them to orchestrate attacks using eBay's own Sign In page. Registered users of eBay's popular online auction web site must sign in using a username and password in order to participate in bidding and listing of items. A new style of attack reported through the Netcraft Toolbar community shows fraudsters exploiting flaws on the Sign In page and on another ancilliary page which results in victims being redirected to the fraudster's site after they have logged in. This particular attack starts off like many others, by sending thousands of emails that instruct victims to update their eBay account details by visiting a URL. However, that is where the similarity ends, because the URL in this case actually takes the victim to the genuine eBay Sign In page, hosted on signin.ebay.com. By including special parameters at the end of the URL, the fraudster has changed the behaviour of the Sign In page so that when a user successfully logs in, they will then be sent to the fraudster's site via an open redirect hosted on servlet.ebay.com. The eBay Toolbar reports that the maliciously modified Sign In page is a "Verified eBay Site". Conversely, the Netcraft Toolbar denies access to the modified page while still allowing access to genuine eBay Sign In pages. The victim is more likely to trust the contents of the fraudster's site, because they have arrived there as a result of signing into eBay via a genuine eBay Sign In page. Because there is less reason to suspect anything is awry, the victim is more likely to surrender any sensitive details in the mistaken belief that they are really giving them to eBay. Theft of eBay and PayPal accounts is of particular interest to fraudsters, as they can be used to launder money and list auctions for high value goods, piggy-backing off someone else's positive feedback.
I received one such email yesterday, I'm sure that there are thousands of these floating around. However, my netcraft toolbar (which I have installed, instead of the google toolbar) helped me, as the page was denied access. Hopefuly after reading this there may be several of you who may upgrade their browser toolbar to netcraft's toolbar from their current one as thats one toolbar I TRUST. & for those folks who just do not like installing toolbars, well, here's a tip. Simply "DELETE" all emails you receive that ask you for some sort of verification or information update.

Sunday Jul 17, 2005

pam_ldap and nss_ldap Plain text authentication leak

GLSA 200507-13
1. Gentoo Linux Security Advisory Version Information Advisory Reference GLSA 200507-13 / pam_ldap nss_ldap Release Date July 14, 2005 Latest Revision July 14, 2005: 01 Impact normal Exploitable remote Package Vulnerable versions Unaffected versions Architecture(s) sys-auth/nss_ldap < 239-r1 >= 239-r1, 226-r1 All supported architectures sys-auth/pam_ldap < 178-r1 >= 178-r1 All supported architectures Related bugreports: #96767 Synopsis pam_ldap and nss_ldap fail to restart TLS when following a referral, possibly leading to credentials being sent in plain text. 2. Impact Information Background pam_ldap is a Pluggable Authentication Module which allows authentication against an LDAP directory. nss_ldap is a Name Service Switch module which allows 'passwd', 'group' and 'host' database information to be pulled from LDAP. TLS is Transport Layer Security, a protocol that allows encryption of network communications. Description Rob Holland of the Gentoo Security Audit Team discovered that pam_ldap and nss_ldap fail to use TLS for referred connections if they are referred to a master after connecting to a slave, regardless of the "ssl start_tls" ldap.conf setting. Impact An attacker could sniff passwords or other sensitive information as the communication is not encrypted. 3. Resolution Information Workaround pam_ldap and nss_ldap can be set to force the use of SSL instead of TLS. Resolution All pam_ldap users should upgrade to the latest version: Code Listing 3.1 # emerge ——sync # emerge ——ask ——oneshot ——verbose ">=sys-auth/pam_ldap-178-r1" All nss_ldap users should upgrade to the latest version: Code Listing 3.2 # emerge ——sync # emerge ——ask ——oneshot ——verbose sys-auth/nss_ldap 4. References CAN-2005-2069 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2069 http://www.gentoo.org/security/en/glsa/glsa-200507-13.xml

Saturday Jun 25, 2005

Java Cards - A MUST HAVE

By this coming Monday all major federal agencies are required to submit detailed implementation plans to the White House Office of Management and Budget that describe how they plan to meet the smart-card requirements outlined in Federal Information Processing Standard (FIPS) 201 (download PDF). The 2004 presidential directive requires all federal government agencies to use smart cards to authenticate employees for access to resources.
The requirements stem from Homeland Security Presidential Directive 12, which calls for electronic identity cards to be issued to all federal employees and contractors as part of a bid to better secure access to government facilities and information systems. The cards must support two-factor authentication via digital certificates, a password or personal identification number, and biometric identifiers. They also are expected to be interoperable across all federal agencies.
SmartCards aka Java Cards are effective... very very effective. The Java Card Development Kit, includes a complete environment in which applets written for the Java Card platform can be developed and tested. It enables developers to create applets that utilize the features of the Java Card API. Now : This technology is not something new. We've been at it for ages... Why do folks shudder with reluctance when they are given new technologies to play with? Well, ask us, and we shall show you how ;-) According to this report, Taiwan had distributed Java Cards to it's population (22 million) way back in 2003. So did Taiwan, India, China and others... (I just cannot find those reports, I shall provide you links to those reports as soon as I find them) This article that dates back to 2000 would show you that we truly are the early adopters of this technology. So why is the federal sector still fumbling with their deadline for deployment soon approaching.
Sometimes It's best to let the experts show you the way. Why not ? Haven't you seen the Sun folks walking around with Java Cards for a while now ?
and hey, The DoD nomenclature for Java Cards is CAC (Common Access Card), and who do you think is behind it ?? Well, truthfully, the peices of plastic are from Schlumberger, the card readers for windows are from ActiveCard and THE REST, By US !!! ;-) Java Card technology is one of the best secure authentication technologies for trust, privacy and verification of identity on the network, deployed in way over 500 million smart card and mobile phone environments around the world. Sun is building on this success and applying its expertise to the Windows environment though inclusion of Java Card technology support in its Java Desktop System and Java software systems. This model will not only secure access to the device (mobile handset, desktop or infrastructure), but access to network services, and ultimately access to and distribution of content. This guarantees authentication of the device, of the sender, and of content represented, helping reduce victimization through fraudulent Web sites, and e-mail spam and viruses.
Think about it feds.. You got our number.. (and if you didnt know it, it's +1-800-786-0404)

Tuesday May 31, 2005

Secure Passwords

"Jot Down Your Passwords" : said Jesper Johansson the senior program manager for Security and Policy Services at Microsoft Speaking on the opening day of the AusCERT conference at Australia's Gold Coast Resort. He continued to say
Companies should not ban employees from writing down their passwords because such bans force people to use the same weak term on many systems. How many have (a) password policy that says under penalty of death you shall not write down your password? I claim that is absolutely wrong. I claim that password policy should say you should write down your password. I have 68 different passwords. If I am not allowed to write any of them down, guess what I am going to do? I am going to use the same password on every one of them.
He's got a point in what he's saying. Organizations enforce password policies on all their enterprise applications, sometimes strict and sometimes, weak. However the mininal feature that these password policies have is that they all expire in a pre determined period and sometimes we cannot use the same password as what had used before (or it just cannot be the same as the previous 6 password changes). This makes it extremely hard over a period of time to come up with really strong passwords and more importantly remember them. Well, I have forgotten quite a few myself, and then asking for a password reset with the support folks absolutely goes against the intent of the organizations establishing a "self service" portal for their employees. Then on the other hand, writing down passwords on a piece of paperas suggested by Johansson is simply ridiculous. The probability of that very piece of paper getting into the hands of a unintended recipient is extremely high.

I then remembered, Yahoo's webmail service allows their users to login to their mail accounts with a YahooID and password over HTTP. They DO have a feature where the user can switch to a secure mode and then enter his "login credential" and submit it over HTTPS. But how many folks really cick on the term "secure". If one types in https://mail.yahoo.com in their browsers address bar, they are immediately prompted with a WARNING that he certificate presented DOES NOT match the URL (because the cert is issues to login.yahoo.com instead of mail.yahoo.com.). WOW!!! So I did a little more digging around yahoo, and I found out that they are using this NEAT open source script by Paul Johnston which is a JavaScript implementation of the RSA Data Security, Inc. MD5 Message Digest Algorithm, as defined in RFC 1321. Thats a real cool one. I was impressed, (not with Yahoo, but Paul Johnstons script). NOW Thats a way in which passwords can be kept safe. So I went ahead and used that very same script (from yahoo/pajhome)on this site and modified it a little bit to concatenate 2 strings and here's what I came up with: A JavaScript version of obtaining a MD5 Hashed equivalent of you password thats unique for each site you use it on. Which obviously means that if your password is "hello" then the MD5 equivalent of that password on "sun.com" would be different from "yahoo.com".

Cheers !!! :: & I am really looking forward to your comments on this.

Rohan Pinto


« August 2016
My Bookmarks
Currently Surfing