How To Break Web Software - A look at security...

I found below video on youtube and liked it. It is little longer in duration but worth watching.

Oracle database security and PCI DSS

Today I was browsing for data masking technology and products available in this space and found one good link on the oracle site.

This link explains each PCI DSS requirements in detail.

Strong Authentication by biopassword

I watched many sci-fi movies where guys were playing around on the keyboard and trying to hack someones system by figuring out password etc. You already know that every individual has his/her own way/speed of typing on the keyboard. Biopassword has made a product on such grounds. There product captures the keystrokes and builds a pattern in which user key in the password etc. During authentication there software checks for that pattern and denies the access if the pattern does not match. I have tested the demo on there site.

You check it out by yourself and have fun.

SAML and desktop SSO

Today I was reading a post and found one good blog which i would like to share with you. PingIdentity has developed Integrated Windows Authentication toolkit to provide SSO to Google application.

If you have read my post onSAML where I discussed how Google apps are using SAML for federated authentication to there applications like gmail/gtalk used by corporates with there domain like abc@company.com hosted using gmail interface. In that post I have mentioned under section 1-a that if user is already authenticated then identity provider will not ask for the credentials again to the user but directly give access to the Google application like gtalk/gmail etc.

Below diagram shows my understanding of how it might be working. I am not showing anything related to pingidentity implementation for this approach but it is completely my understanding for the solution.

Microsoft GINA component can be customized to get the user credential and Microsoft has also exposed API to set the cookie for Internet explorer. Keep in mind that all things are going through the user browser so if user has a cookie to some domain (identity provider) it will be sent to the server by the browser.

Similarly Cookie can be deleted on the event of user logout. If the solution needs persistent cookie can also be set which will expire after the persistence time.

ProQuo Implementation of centralized identity

Many people staying in USA (Sorry for being location specific as this implementation is done for USA) are suffering with tons of junk mails coming to there mailbox (Physical mailbox). Here publisher/marketing organizations send lots of advertising material to the mailbox which (80-90%) directly been dumped into the trash box next to the mailbox. It consumes billions of dollars cost of paper and postage.

This new site is a good effort to stop this unnecessary mails coming to your mailbox. Once you login/register at this siteProQuo it will display all the publications which you are getting. After registration you can view your current publications by clicking on the dashboard link.

Below image shows how ProQuo might be getting the publication information's from different marketing organizations.



Once a person registers with his [name/email and address] this site can show how many publications you have. They might able to collect this information based on your identity (Name + Address).

When I registered on this site and tried to stop some of the publications I got stuck with some paper work (You have to take the printout of the PDF file which has the letter to stop the publication and post it to the publisher). Problem with this is that most of the people have at least 10-15 publications. Every publication post is going to cost 50 Cents so roughly 5$ per household to stop all the junk publications.

Identity Solutions:

I feel that the wired solutions can be built to stop the physical communication between the user and the publisher. Following could be some of the ways to implement this

1) Using SAML: user assertion can be sent to the publisher over the wire. This SAML assertions can also contain the encoded PDF letter which can be used as a proof at the publisher.

2) Using custom Cryptography: User's signed PDF can be sent to the web service running at the publisher when user want to stop the publication.

Share your comments about how it can be implemented.

Technorati : federated identity management, identity control, identitycontrol

How Kerberos was evolved - Inside Story Part 2

In my last post I discussed few steps for the evolution of kerberos protocol implementation. In this post I am going to conclude it so read on...

Just want to recolect the problem statements where I left in last post so you get some continuity

Problems

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

For solving first problem Authentication Server (Ticket Granting Server [TGS]) will generate a sessionkey which will be sent to the user. TGS will also send a ticket encrypted with service password to the user. Below is the detailed structure

[SesssionKey:[*Service Ticket encrypted with service Key]]

* Structure of service ticket is [SessionKey:lifespan:issuing time:service name]

issuing time and lifespan are introduced so tickets can be valid for specific amount of time and not good for ever.

TGS will encrypt session key and ticket with user's password to solve the replay attack because password is only shared between user and Authentication Server.

Step by Step process for user authentication and service access

1) User enters the userid and KINIT program on the user machine sends that to TGS for authentication.

2) TGS server creates Ticket Granting Ticket [TGT] (this will be used to get service tickets)and send to the user by encrypting the whole content by users passwod.

3) User decrypts the TGT using the password to get the ticket. If someone spoof the packet then he will not be able to decrypt it as the password is shared between user and TGS only.

4) User wants to access his mail but user does not have mail service ticket so user contacts TGT for mail service ticket by submitting Authenticator,TGT, Name of the user and workstation address. This Authenticator with the session key sent by the TGS in the initial handshaking.

* Authenticator = {username:servie name: time stamp : lifespan}

5) TGS will get the session key of the user and decrypts the authenticator. After validating the identity it generates following and send by encrypting the whole content using the SESSION Key.

i) Ticket for the mail service. This ticket has the session key, service name, lifespan, timestamp and client address. This ticket is encrypted with the service password. (Even User can not decrypt it)
ii) Session key to be used to encrypt the conversation with mail service

6) User recieves the packet and decrypts the content using the session key (Given during first handshake with the TGS).

7) User prepares the Authenticator and encrypts it with the SESSION key (generated for the mail service communication in step 5).

8) Mail Service recieves the Authenticator and Ticket. Decryptst the ticket using it's password to get the session key. Using the session key decrypts the Authenticator. Validate the Authenticator and sends the acknowledgement to the user by encrypting the session key.

9) User receives the acknowledgement and start using the service.

How Kerberos was evolved - Inside Story Part 1

I always wanted to get something on kerberos (earlier name Charon) which can give me inside of the protocol like why,how, what etc...

In this post I am trying to explain this in some easy steps with problem and solution approach for the evolution of this protocol.

Below Image displays the first version of there discussion



Problem with the first version is that anybody can impersonate anybody easily so no security and accountability. There is no Authentication (NO PASSWORD) piece involved it is just the userid which you pass to get the service.

Below Image solves first problem by having a centralized authentication server. Every user and every service has a password which is stored in the authentication server named CHAROS.

Here is how it work

1) User Authenticates with the centralized server
2) Server authenticates the user and give him a TICKET (encrypted text which is encrypted with service password)

*encrypted text contains (Username and servicename and IP address of the user)
3) User passes this ticket to the service and service will verify user's identity to give access




Problems with this:

1) User has to authenticate every time user wants to use any service. For example user has got the TICKET for mail service but wants to print some mail then he has to again enter the password
2) Password is flowing on the network in clear text (people can capture the password on the network)


Above problem is solve by introducing another component called ticket granting service in the authentication service. It will grant the ticket which can be reused.

Another componet which is added at the system level is KINIT service which is responsible for handshaking with the authentication service. Here is how it works

1) KINIT service will take userid and password from the user and will pass the userid to the authentication service (it will NOT pass the password at all)
2) Authentication service will build the TICKET GRANTING TICKET and encrypt it with the user's password because it knows what the user password is.
3) KINIT will decrypt the token using user's password. If it is able to decrypt it successfully then user is authenticated.





Problems:

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

Keep reading this because I will post rest of the story in next post...