187 reputation
7
bio website adventure-inn.com
location Costa Rica
age
visits member for 3 years, 1 month
seen Aug 26 at 23:12

Aug
10
comment Are there any flaws in my design for a paper-based OTP grid?
Great ideas, Andy. Thanks for your help.
Aug
10
accepted Are there any flaws in my design for a paper-based OTP grid?
Aug
10
comment Are there any flaws in my design for a paper-based OTP grid?
I understood what you meant too, so in the end I decided to remove the whole _rstr2any() method and replace it with a simple mt_srand(crc32($hash)); and then use mt_rand() to choose the "random" numbers that become the cell values. That way I avoid any of the problems you mention since the values always come from mt_rand().
Aug
9
comment Are there any flaws in my design for a paper-based OTP grid?
The reason I thought of passing the hash through the "mathematical formula" was to make it so that for the same id and random string, it will always produce the same output and would therefore allow me to verify values from it. I thought of just feeding it through the random number generator again, but according to the docs, it accepts an integer, not a string. However doing a bit more research, I just found this article which seems like a promising way to seed the RNG with a string.
Aug
9
comment Are there any flaws in my design for a paper-based OTP grid?
What's your take on my question about whether it's better to use pseudorandom vs unique values?
Aug
9
comment Are there any flaws in my design for a paper-based OTP grid?
You know, you're probably right. If I'm storing everything needed to generate the characters in the database, I might as well just store the whole character sequence in the database. What matters is the end result, not how to get there. Good point. And of course, this will be combined with a conventional username/password as well as other checks to temporarily lock accounts after too many failed attempts.
Aug
9
comment Are there any flaws in my design for a paper-based OTP grid?
@AndyBoura I may use Google Authenticator as well, but not everybody has a cell phone, which is why I thought of going this way.
Aug
9
asked Are there any flaws in my design for a paper-based OTP grid?
Apr
29
comment Can IP address be a component of 2-factor authentication?
The last line should be "and something you know (the passphrase's key)."
Mar
25
comment How does Amazon bill me without the CVC / CVV / CVV2?
@deed02392 After researching it a bit, I found this site which says "big players in the U.S. consumer-sales industry have developed informal agreements with credit-card issuers that allow charges to be made to consumers' credit cards without specifying the expiry month and year". So it looks like the big guys get to do whatever they want while small merchants (like us) don't have these special agreements. So what I said above is not entirely true.
Dec
21
comment How does Amazon bill me without the CVC / CVV / CVV2?
You certainly DO need the expiration date to charge any card. We charge cards manually all the time, but this is impossible without the expiration date. I would assume it's used as sort of a "control" since card numbers can easily be generated by trying numbers and feeding them into the Luhn algorithm. However the expiration date cannot be validated programatically.
May
16
awarded  Popular Question
Feb
12
comment Regulations that specify password length?
@Rook Good point. However hashing a 15 character password or a 1000 char password isn't going to really make a big difference. But I guess there should be SOME limit enforced, just nothing even close to being in the range of what 99.99% of normal users would provide.
Feb
12
comment Regulations that specify password length?
@Iszi Easy. When changing passwords, prompt the user for their previous one.
Feb
12
comment Regulations that specify password length?
How on earth does a maximum password length improve security under any circumstances? Just yesterday I was changing my live.com password and they give you all this stuff about security being so important to them blah blah blah, but then they cap password lengths at 15 characters.
Jul
4
revised Do most browsers handle mixed encrypted and unencrypted content correctly?
added 363 characters in body
Jul
4
accepted Do most browsers handle mixed encrypted and unencrypted content correctly?
Jul
4
comment Do most browsers handle mixed encrypted and unencrypted content correctly?
And as for security depending on "what's going through", when it comes to application development, ALWAYS assume the worst and prepare for it. If an HTTPS page can have absolutely nothing of interest, great. But it can also contain your bank account information, social security number, credit card number, PayPal account info, etc. My question wasn't "is it always a bad idea", but more along the lines of "could it ever be a bad idea in any circumstances, no matter how obscure". If the answer to the second is "yes", then browser developers should prevent this from happening.
Jul
4
comment Do most browsers handle mixed encrypted and unencrypted content correctly?
I'm not sure I agree about you of the Chrome notification being barely present. First, because it is pretty plainly visible at the top of the page. Unless your page had a very similar colored background, not many users would miss it. Second, because it doesn't matter. Why? Because the browser doesn't load any HTTP content until specifically allowed by the user. I also, personally don't see any usability loss in doing it the Chrome way.
Jun
30
asked Do most browsers handle mixed encrypted and unencrypted content correctly?