Hi all,
I appreciate this idea, simple and powerful to achieve proof of possession.
But, I have some questions against the scheme.
Sorry if these ware already discussed.
I worry about using a hash function in simple way.
I mean, a simple use of random as code_verifier may cause that malicious cl
the spec, as you are not the only person
> asking that question.
Thank you.
>
> The other issue is that the term HMAC is scary to developers and we want
> maximum adoption.
>
> John B.
>
> Sent from my iPhone
>
>> On Nov 13, 2014, at 3:28 PM, takamichi saito
t isn't then the attacker could be stealing the original
> credential used to authenticate anyway.
>
Is it correct?
You mean that we don’t need to use hash itself? Only to use plain is enough?
>
>
>
> On Thursday, November 13, 2014 5:40 PM, takamichi saito
> wrote
I will come up with some text for the spec, as you are not the only person
> asking that question.
>
> The other issue is that the term HMAC is scary to developers and we want
> maximum adoption.
>
> John B.
>
> Sent from my iPhone
>
> > On Nov 13, 2014, at 3
code to be tried once
>> -at a very minimum should have a severely limited number of tries for a
>> code
>> -a short time window to use a code
>>
>> Unless you can brute force 256 bits of (pseudo)random in under a minute or
>> two the code is dead. G
challenge is only one time use and has a short
validity period. " from the start, and I said so.
So, the attacker can not have "code_verifier" within the attack time.
"John's comment on brute force" is not my concern.
My concern is the above constraint against att
equired for the basic functionality/security
of the mechanism.
In the threat model of the SPOP scheme, a wiretap is in it.
And more, the hash is not used to keep secretly in the sever/client.
On Thursday, November 13, 2014 7:07 PM, takamichi saito
wrote:
Sorry for my poor english.
2014/1
rote:
I am actually not convinced. Since the code verifier is 256bit random,
adding salt does not seem to help.
Salting definitely helps if len(password) << 256 bit, but ...
On Mon Nov 17 2014 at 11:39:07 takamichi saito mailto:sa...@cs.meiji.ac.jp>> wrote:
(2014/11/14 1
I never confuse about password in these discussions.
Regards,
-bill
On Monday, November 17, 2014 7:27 PM, takamichi saito
wrote:
I agree that GPU can/may find the value on the fly.
But, it can not find it within the session.
The draft idea is enough against the attack with GPU.
On the other,
dence that shows that precomputing hashes would
be an effective attack against 256 bits of entropy. I agree that
it would be agains the 40 ish bits of entropy in a password.
The likely mitigation is using PBKDF2 or BCrypt rather than SHA256,
but that would slow adoption a
adding entropy, but never
actually justifying it.
Adding client_ID is not only for like adding password's salt.
Adding client_ID is not same as adding password's salt in this context.
On Monday, November 17, 2014 8:34 PM, takamichi saito
wrote:
(2014/11/18 13:17), Bill Mills wrote:
done faster
> than 3 Giga SHA256 Hash/s.
> on a small system http://thepasswordproject.com/oclhashcat_benchmarking
>
> I don't think the largest disk arrays can keep up with that.
>
> Do you have some evidence that shows that precomputing hashes would be an
> effectiv
On 2014/11/19, at 18:01, Sergey Beryozkin wrote:
> Hi
>
> Apologies for getting into this thread (I do not understand most of the
> mathematics at this stage :)),
> On 19/11/14 06:43, takamichi saito wrote:
>> (2014/11/18 13:54), Bill Mills wrote:
>>> There will b
13 matches
Mail list logo
