Re: Encrypt a UsernameToken Authenticated WSE Response

lets use your example : sunshine;12
so a word, a special character, and a number
lets assume that it is not case sensitive
(to make it significantly easier)
and that the order is always word, character, number
(to make it significantly easier)
sunshine is a common word that will be in a 200K word dictionary
so lets make the search space
200K words * 10 special characters * 100 digits
= 200000000
so your program could find it in 200 minutes (worst case)

now lets take a passphrase of just 2 words
200K * 200K
40000000000 search space
that would take you about a month (worst case)

add another word, case sensitivity, or a number,
and it becomes significantly harder.

which can be beaten by more powerful computers,
and parallel computing.

i use SALT on the client side too (sent as plain text),
to avoid a direct DB lookup of the hash value,
to force the cracker to do the brute force search.
(although UsernameToken has nonce built in)

key management does not require a cert.
with or without a cert, you still have to manage the pub/pri keys.
and most people cant manage their passwords.

it depends on how secure you need to be,
but i definitely think passwords (particularly pass phrases) have their
place.

Thanks,
casey
http://www.brains-N-brawn.com


"William Stacey [MVP]" <staceywREMOVE@xxxxxxxx> wrote in message
news:OVfv9cdNFHA.3760@xxxxxxxxxxxxxxxxxxxxxxx
>> if the password is a word in the dictionary, then its definitely simple.
>> all you do is run through the 200K to 400K words used in a language.
>> so make the password a non dictionary word, or better yet a passphrase.
>
> That is generally good. However, my home P4 2.4Ghz computer can test
> about
> 1 million passwords (dict or hybred) per minute. So even passwords like
> "sunshine;12" will be cracked in short order. Passphrases are more work,
> but could still get many of those with more time. Totally random
> passwords
> are probably the best against this attack. However, in the real world,
> neither is widely used by users as they forget those passwords and regress
> back to something they can remember (normally some dict word with just
> enouph digits appended or prepended to pass the password policy.)
>
>> you can also make is stronger by prepending SALT.
>> you should be using SALT server side anyways.
>> of course all that can be beaten, but its not exactly easy.
>
> Salt does not add much to the wire security - only the server db security.
> That is because normally salt is sent to the client in clear text so it is
> known. If the client gets the salt via some encryption, then we are back
> to
> how to get a secure session. And if we already had one, the client does
> not
> need the salt.
>
>> or you could use x509 as your blog says,
>> and mess around with key management.
>
> x509 or just your own RSA keys that does not require certs. I blogged a
> SCT
> solution using just strong name public key on client side to get a SCT.
>
> --
> William Stacey, MVP
> http://mvp.support.microsoft.com
>
>


.

Relevant Pages

  • Re: Importance of salt
    ... About passwords in cryptography - there are tons of resources, ... Passwords and Offline Guessing Attacks. ... > I have one question regarding the importance of salt in encryption. ... the salt is used to prevent dictionary attacks. ...
    (microsoft.public.dotnet.security)
  • Re: Authenticate a User.
    ... > contain crypted passwords. ... >> That is because the salt may be longer than 2 characters. ... This is true if you're using the MD5 version of crypt, ... then a longer salt is obviously a possible explanation. ...
    (comp.os.linux.development.apps)
  • Re: Importance of salt
    ... Dominick Baier - DevelopMentor ... > About passwords in cryptography - there are tons of resources, ... >> I have one question regarding the importance of salt in encryption. ... the salt is used to prevent dictionary attacks. ...
    (microsoft.public.dotnet.security)
  • Re: Encrypt a UsernameToken Authenticated WSE Response
    ... million passwords per minute. ... > you can also make is stronger by prepending SALT. ... That is because normally salt is sent to the client in clear text so it is ... I blogged a SCT ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • RE: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
    ... through an entire shadow file for the hash. ... In the case of the postgres passwords, the user name seems to act as a ... sort of "public" salt. ... > pre-computation of a dictionaries infeasable due to storage ...
    (Bugtraq)