zhuzhuor's comments

I had a BB 9800 and a BB 9900 before, and switched to Android phones for couples of years. From my own experience, BBM is still the most stable and comfortable IM app on mobile phones.

I still miss the feeling about using BBM. I guess the backend service part of RIM/Blackberry is still somehow ahead of other manufacturers.

It is very interesting to see Twitter has the similar idea with ours.

We just submitted a research paper 2 weeks ago to SPSM'13 (http://www.spsm-workshop.org/2013/). We proposed a password-free login system, of which Twitter's new 2-factor auth solution is a special case. We also discussed about the solutions to vender lock-in and 2-factor auth in the paper.

I put the paper in public for interested readers. You can download it from http://about.bozhu.me/paper/loxin.pdf

PS. We did a conceptual Android app about password-free mobile payment, under the same idea, in last year when we participating in the MintChipChallenge by the Royal Canadian Mint. The source code is available at https://github.com/Xecurity/EasyChip

For anyone who might be interested, I made a client-side javascript clone of gist.io.

It supports listing gists with specific tags, such as "blog" (along with other features, e.g. custom css/js/html and latex)

Home page: http://jist.in

Source code: https://github.com/zhuzhuor/jist/

I sincerely doubt how ease and stable a local (actually home-based) service can be compared to cloud-based service.

thx, this is awesome!

It's an old story about Tom Skype. I have known Skype has two different versions for China and other countries for years.

Why do you so emphasize Microsoft in the title? Because it's Microsoft?

Does any one have problems to create or modify a gist? I am having the problem since this new face of gist.

Now it's still not fixed in my case. What happened to github?

Me too... going to disable any gmail/gtalk extension to see if it would be more stable

OK... I assume it's not a phishing site, which requires your phone number and password...

You didn't get my point...

I know what it is based on, except the implementation details.

My question was what's the mechanism to verify the code refreshed every time the screen is turn on (which is a little different from other authenticators).

Thanks

Please read my comment to @danielpal.

By self-verifiable I mean the half of the code is a random number, the other half is computed based on the secret seed and the random number.

I guess another way without frequent sync is to generate a new code every sec, and the server check if it's one of the 25 codes in the last 25 seconds. But this might be unnecessary and inefficient.

Thanks for your explanations. I didn't get your details but I did more experiments. You may tell me if I am wrong.

1. If my phone has Internet connections, whenever the screen is turn on, the code is refreshed.

If the code is solely based on time, the app may sync its time tick with the server every time when it's turn on.

If the app sends its time to the server, the synced time value should also be encrypted and authenticated. The only pre-shared credential is the 6-digit pin sent by sms, which might be a little short.

If the app gets the time from the server, it might have a slight time delay before the code is computed and shown due to the network latency.

2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s.

So I guess every 5s the app will generate a new code for the next 0~25s.

When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s.

So at least 5 different codes should work in the same time. This may be a nice way.

I don't think it is solely based on time. Did you read my comment carefully?

I'm a little puzzled by the way authy works.

It seems to me the authy app refreshes a new code whenever I turn the screen off and on. I don't know how it syncs with the authentication server. The app must not only based on time ticks, like other 2-factor apps.

One way I thought is to notify the authentication server in background network requests. But I guess this isn't the case, because it won't work if you don't have network signal (you can try it in the airplane mode).

The other way I thought is the code must be self-verifiable. That means half of the code is a random number, and the other half is the real code computed based on the rand numb and some credentials. If it is really in this case the security strength is only half of the length of the code, i.e. 3.5 digits. That's not very safe to me, especially the website of authy itself only needs one code to log in (without any `first-factor` password).

Any thoughts?

IMHO, the unnecessary require statement is a fairly solid evidence.

And programming is like English writing, no one will actually produce the same code. You can try by yourself

If no license is specified, then the author(s) have all the rights.

Just to add another fact here: Daemen is also one of the two co-authors of AES

does Google have customer service?

one more step closer to monopoly