[Owasp-Mumbai] (no subject)

chintan dave davechintan at gmail.com
Mon Oct 20 09:10:57 EDT 2008

Hi Harpreet,
I appreciate the effort you guys have put in to come up with something new
and innovative. I have some confusions still.

1) Why do you guys want to reinvent the wheel? You can anyways use RSA
tokens for 2 Factor Authentication. It is known to be a robust protocol.

2) Coming to your point, lets assume you need something like that, or its an
innovative idea. I think the design has a room for improvement from a
security analyst's point of view. The golden rule of application security is
"Never trust the client". So its not an advisable thing to implement
validation on client side.

3) Appending the hash value generated for second factor authentication in a
cookie as a value is also a risk, as cookies are transmitted in plain text
over the network, unless the communication channel is explicitly encrypted.
This might forfeit the purpose of having second factor authentication, as
the second factor authentication credentials can be sniffed and reused.

4) If it is stored on the local file system, it is still prone to attacks.
(E.g. cookie manipulation). Do not assume that the user will not temper the
file on his local file system. Replacing the hash value stored in the file
with sniffed hash value (which identifies another valid user) should work
(since both the hash values are server generated and valid). I think the
design can have potential security concerns if not re-examined. You have
done a smart work by taking an opinion before implementing the design. You
saved a lot of effort this way, as re-designing might have taken too much of
effort and money.

I hope i have answered your question.


On Mon, Oct 20, 2008 at 6:59 PM, Harpreet-Singh <harpreet at ncb.ernet.in>wrote:

> Hi,
> Further to my previous mail regarding my project on Authentication. Please
> find below a brief writeup of the project.
> The project is based on a research paper published on "providing Two
> factor authentication" by one of our colleagues.
> The second factor is considered as smart card (Javacard) in the paper. But
> as the cost of Javacard is high we have decided to simulate the smart card
> as SMART CARD FILE which is at present a txt file generated after each
> successful registration and containing the resultant hash computations.
> In actual implementation with hardware based smart card the authors
> proposed to issue a personalized smart card to each registered user
> through reliable channel (courier etc.). The personalization here includes
> some computations such as hash functions, XOR operations done using the
> user credentials (userID , password)
> Registration Phase
> At the time of registration, once the user finishes his registration
> formalities and submits it to the server, the server does some secret
> computations and writes it in a smart card file which is to be delivered
> to the registered user (according to the paper). But since we can't expect
> every user to have a removable media such as thumb drive etc. to download
> the software smart card, we are writing the file contents in the cookie
> and storing it on the user system. Moreover, if the user at registration
> time says that he is registering from a public place (cyber caf etc) then
> the cookie will be stored on the system for limited time period say 6 hrs
> before it automatically gets expired.
> Login Phase
> At login, if the user is accessing the account from his own PC, he enters
> his userID which is verified locally with contents of the cookie. If local
> verification is successful then the client sends it to server for
> validation. Upon successful validation at server, the server sends the
> password page where in the user enters his password which is also locally
> verified. After password verification, the client prepares a secret
> message using the validated values and sends it to the server. The server
> does validate it before providing the access to account.
> If every time the user logs in from different systems then after user
> enters the ID, the system checks if his cookie is present. If it is not
> available then the server asks some secret questions (questions which are
> usually asked if user forgets password) to be answered by the user. If
> answers are correct then the server loads the smart card file as cookie
> from its backup to the client. The rest of the process of asking the user
> to enter password etc. follows as discussed above.
> ------------------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------------------
> Hi All,
>  I am currently developing an authentication project in Java which
>  requires few of the user credentials to be stored on client after
>  successful registration. This is to enable the client to locally
>  verify the userID and do other necassary computations before it is being
> sent
>  to server. As of now, I am storing these in default cookies location
>  at client. But if the user has disabled the  cookie option or clears
>  the cookies then the authentication process cannot proceed. We are
>  thinking that we can store the cookie in some other location other
>  than the default location.
>  In view of the above I have two queries.
>  1) Is there any way to store the cookie in some different secret location
> (such
>     as windows system directory etc.) from where the cookie can be read at
> login time.
>  2) If we want to store the cookie in different location then how we
> cannot identify
>     the type of operating system running at client (as Linux as client
> will have some
>     different directory)
>  I request you to kindly take some time out to give the best solution
>  for the same.
> Thanks & Regards
> Harpreet
> _______________________________________________
> OWASP-Mumbai mailing list
> OWASP-Mumbai at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-mumbai

Chintan Dave,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-mumbai/attachments/20081020/563d8b09/attachment-0001.html 

More information about the OWASP-Mumbai mailing list