61–70 of 75 posts
Earlier quoted context omitted.
Is it possible that the app runs in sandbox? Or is that already the case?
> Is it possible that the app runs in sandbox? Or is that already the case? Why does that matter?
It annoys me that a trick is missed with the secure fob. Imagine that: the challenge screen includes the amount you are authorising and you type that amount into your secure fob along with the challenge code That's basically how the auth works on with my online bank. I get a small calculator sized device that reads my debit card. I have to enter the card pin, a challenge code from the online transaction, and the amou…
It annoys me that a trick is missed with the secure fob. Imagine that: the challenge screen includes the amount you are authorising and you type that amount into your secure fob along with the challenge code That's basically how the auth works on with my online bank. I get a small calculator sized device that reads my debit card. I have to enter the card pin, a challenge code from the online transaction, and the amou…
Does it read your card (magnetic strip) or it uses the card's chip for encryption services to generate the tokens? It's not the same thing. Card chips are not easy to clone and have more data than the credit card number.
Earlier quoted context omitted.
> Is it possible that the app runs in sandbox? Or is that already the case? Why does that matter?
So that other applications cannot steal the generated code. I think the easiest way to steal the code is to OCR a screenshot.
Earlier quoted context omitted.
Does it read your card (magnetic strip) or it uses the card's chip for encryption services to generate the tokens? It's not the same thing. Card chips are not easy to clone and have more data than the credit card number.
Good question. No idea :-)
NIST recommends PBKDF2.
In short, it appears that advances in hardware have made it possible such that bcrypt hashes can be efficiently computed.
http://en.wikipedia.org/wiki/PBKDF2 http://security.stackexchange.com/questions/4781/do-any-secu...
Bcrypt is no longer recommended. NIST recommends PBKDF2. In short, it appears that advances in hardware have made it possible such that bcrypt hashes can be efficiently computed. http://en.wikipedia.org/wiki/PBKDF2 http://security.stackexchange.com/questions/4781/do-any-secu...
Bcrypt is no longer recommended. NIST recommends PBKDF2. In short, it appears that advances in hardware have made it possible such that bcrypt hashes can be efficiently computed. http://en.wikipedia.org/wiki/PBKDF2 http://security.stackexchange.com/questions/4781/do-any-secu...
The bcrypt key derivation function requires a larger (but
still fixed) amount of RAM and is slightly stronger
against such attacks, while the more modern scrypt key
derivation function can use arbitrarily large amounts of
memory and is much stronger. (wikipedia)
Basically they recommend PBKDF2. This does not mean that
they deem bcrypt insecure; they say nothing at all about
bcrypt. It just means that NIST deems PBKDF2 "secure
enough" ... On the other hand, bcrypt comes from Blowfish
which has never received any kind of NIST blessing (or
curse). (stackexchange)
Unfortunately, the release of Django 1.4/django-registration 0.8 (https://bitbucket.org/ubernostrum/django-registration/src/27...) complicates matters a bit, and I'm torn between figuring out a way to keep my TFA or just roll it back altogether and implement d-r, and see if it has support for TFA.
If you're using Django 1.3 with something else than the default password-hashing, you should check out django-TSA.