On Fri, Dec 14, 2012 at 5:12 AM, Rajiv Yadav <rajivyada...@gmail.com> wrote:
> Hi all,
> I have an easy and basic approach for doing this:
> .
>
> 1. getKey(uuid, timestamp)
> It will call the server and get a tempary key and service will store
> uuid and timestamp, and key
>
> 2. Login(encrypted-key,username,other credentials....)
> password will encrypt the key by MD5 and send it back to server
>
> 3. Server decrepit the key with password available on server. if key
> matched a authentication token will be generated and stored on table and
> returned back.
>
> 4. We will save the authentication token in our preferences
> and in further requests authentication token will be send
> for authentication.
>
> I question the use of this scheme, especially the UUID and MD5 component.
UUIDs have been a bane in the past, and its use in this scheme set off
alarm bells. You should generate a per installation identifier at random
and use it. Store it in Apple's KeyChain, Android's KeyStore (or KeyChain
in Android 4.0+), or DPAPI on Windows devices. It should not be left
unattended on the filesystem.
MD5 is not invertible (i.e., there is no F'(m) to recover the pre-image),
but it is easily brute forcible via rainbow tables. Lack of salt means the
rainbow tables are already built. If you add salt, the adversary can still
build his own specialized table. Do you use the same salt for all users? If
so, then the adversary has tables for your entire organization or customer
base.
Plus, authentication tokens should never be persisted.
In the end, its easier to use and audit SSL/TLS or VPN (pinning
certificates as required) and standard session management (supply
{username, password}, and get back a token).
Jeff
> On Fri, Dec 7, 2012 at 8:08 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>
>> On Fri, Dec 7, 2012 at 5:45 AM, sampath premarathna
>> <sampathpremarat...@gmail.com> wrote:
>> > But in your solution anyone in the middle can get that token also,so he
>> can
>> > intercept and change the request no?
>> You would run your application over VPN or SSL/TLS. The token is large
>> and random (96-bits or 128-bits), so it can't be effectively guessed.
>>
>> I've also seen static tokens (tokens that are easy to predict or don't
>> change over protocol runs). For example, something clever like
>> device's UUID. Those apps get kicked too because the attacker can
>> guess the token, and we should not be tracking users based on UUIDs.
>>
>> Jeff
>>
>> > On Monday, November 5, 2012 11:52:17 PM UTC+5:30, Jeffrey Walton wrote:
>> >>
>> >> On Fri, Nov 2, 2012 at 12:06 AM, Rajiv Yadav <rajivy...@gmail.com>
>> wrote:
>> >> > Hi i am developing an application which uses restful services. (near
>> >> > about
>> >> > 30 restful methods some are using "get" and some of are "post")
>> >> > It is working fine but in each call throughout the application i
>> need to
>> >> > send some secure data (like username, password in some encrypted
>> form).
>> >> >
>> >> > my question is is there any secure way for this? please suggest
>> >> Yes. You login into the application once with a {username, password}
>> >> pair. You never use the {username, password} again in a request (until
>> >> the server expires the session). If the server expires the session,
>> >> then you have to log in again. In return for a successful log in, you
>> >> get a token to use on future requests. This is coarse grained
>> >> entitlements (can you use the application?).
>> >>
>> >> When a request arrives at the server for services, the request
>> >> includes the token. The server provides the mapping between
>> >> token->user. This is fine grained entitlements (can the user access
>> >> the resource?).
>> >>
>> >> If I see a web app cross my desk that uses {username, password} in
>> >> each request, then I boot the application immediately. Just giving you
>> >> fair warning here since I'm not the only guy who will deny such an
>> >> application.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Android Security Discussions" group.
To post to this group, send email to android-security-discuss@googlegroups.com.
To unsubscribe from this group, send email to
android-security-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/android-security-discuss?hl=en.
