jonoberheide

Hi Paul! I believe your token should automatically resync if you enter three consecutive correct passcodes that are outside (but forward of) the current valid window.

I think that's a fair read. The primary use of that data is for security use cases. Eg. if you're coming from an out-of-date browser or have risky Java/Flash plugin versions, we can notify you to update/remediate.

Another way to look at it: We collect security-relevant information on your device, but not your _personal_ data. In other words, we don't collect your email, photos, contacts, user-generated data, etc.

No prob! I can't claim to be a HN veteran (/me glares at @tqbf), but if I hear people are having issues, happy to help.

Sorry to hear about your experience, Jarwain!

Duo offers a choice of authentication methods, depending on the usability and security requirements of your application or organization.

Duo Push is actually one of the easiest (and most secure) authentication methods, as one of the commenters pointed out:

https://www.youtube.com/watch?v=tPLxe9HUDjY

It might be worth pinging your IT/security dept to ask about enabling Duo Push as an option or to change the policy for SMS passcodes (eg. you can just have one passcode sent instead of ten).

- Jon Oberheide, Co-Founder & CTO @ Duo

If anyone can quickly point me at the CM9 kernel source, I can verify whether or not this is actually patched.

The vulnerability is looking checking to see if the mem_write() function is functional (where the vulnerability was present), which was removed/disabled by upstream AOSP.

4.1 is definitely the most secure Android you can be running currently.

We posted about some of the security improvements in Jelly Bean 4.1 last week:

https://blog.duosecurity.com/2012/07/exploit-mitigations-in-...

We'd love to be able to publish it in the Play Store, but we were informed by Google that the terms of service disallow any apps that check for vulnerabilities, despite X-Ray's good intentions.

It's a weird distinction that they allow AV-like apps, but not vulnerability assessment apps.

X-Ray author here, happy to answer any questions folks have!

FYI, it is possible for unprivileged apps to invoke the INSTALL_ASSET functionality themselves. One such example described here:

http://blog.duosecurity.com/2011/05/when-angry-birds-attack-...

Another variation of that attack is still unpatched, allowing any app to invoke INSTALL_ASSET. Certainly that's not intended functionality and is a bug that will be (eventually) patched, but I wouldn't classify it as FUD.

Yeah, I'm guessing ARM will be ok with respect to GPRs (although I certainly haven't done any benchmarks).

Dug's FUBAR comment was just an attempt cram in as many acronyms as possible...of course the situation is improvable. ;-)

Still at CORE these days?

GRKERNSEC_BRUTE will also trigger for suid binaries (in the case of memprodroid, run-as). See gr_handle_brute_attach() for details.

Yeah, mempodroid is a great example. You'd need to randomize the location of the setuid executable (w/PIE), randomize of the linker, and implement something like GRKERNSEC_BRUTE to prevent trivial local bruteforcing of a usable address.

Speaking of which, spender's recent blog post gives a good overview of some of the grsec/PaX mitigations that would hamper the exploitation of the /proc/pid/mem vuln:

http://forums.grsecurity.net/viewtopic.php?f=7&t=2939

Right, all libaries need to be compiled with -fPIC in order to be randomized. That tends to be much more common than -fPIE.

There's still a large attack surface of native code in the Android platform. I've heard WebKit has a few bugs... :-P

Duo offers a number of features above and beyond Google Authenticator:

- more flexibility in choice of authentication method (voice, SMS, soft token, hard token, Duo Push)

- more supported mobile platforms (Android, iPhone, Blackberry, WinMo, Palm WebOS, Symbian, J2ME)

- more integrations (VPNs, UNIX logins, web apps, etc)

Not to mention all the features that come along with being a fully-fledged authentication service such as account management, fraud alerting, logging, etc. Feel free to give it a shot and decide for yourself. :-)

Disclaimer: if it's not obvious from my gushing, I'm affiliated with Duo. ;-)

Check out the login_duo(8) man page. You can specify a failmode configuration option to fail safe (allow access) or fail secure (deny access) if there is a connectivity loss between your servers and Duo's service.