And hardware too.
More advanced tokens also do more. My bank uses a hardware token for signing transfers and other actions which can include a human readable message or part of the target account number, making MITM much harder.
A definition issue with regard to "token": I sincerely do not think a device with display and keyboard used to sign transactions can be called "token". I'd say something like: trusted signing processor. But then again, I'm not a security specialist.
1. The bank should require a confirmation with your token to send money. If you don't send anything, the attacker can't either.
2. In the future, after the logout timeout, you know the attacker can't even read your account.
It greatly reduces the attack surface you need to worry about. Any attack they do must be right then.
But how often is that really done? And to be honest, it can be quite hard to spot critical bugs or backdoors, just look at http://www.underhanded-c.org/
The bitcoin development community solved the problem of mapping source code to a binary build. Check sums or signatures of binaries is not sufficient. Open source is meaningless if you cannot verify the source maps to the build and you're running critical software with irreversible consequences. E.g. a bitcoin transaction or a dissident being imprisoned from state surveillance eaves dropping on communications.
App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checksum. Which is useful, but inconvenient for this goal.
Something like fdroid may be supportive of this, which would be cool. But I wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a bad user experience / wasted UI space in the vast majority of cases.
Not a particularly useful comment sorry, just "it was possible two years ago if you jumped through some hoops."
And the last time I looked, all the apk-downloaders required your device ID, because Google's API does (for customization reasons) - it's much more of a "you can do this if you emulate a device" than "you can download it". I'm also not sure if the ID works unless you have gplay installed, which you may not have if you're being careful/paranoid enough about security to manually validate apps.
I mean, at the end of the day, it's very easy to verify - if the binary doesn't match what whomever gets when they compile, there better be a reason for it.
Regardless, I don't think this is the biggest problem facing open source.
True, but deterministic compiles are stupendously difficult in most cases. Which is improving slowly, but still isn't usually an option.
https://tests.reproducible-builds.org/debian/reproducible.ht...
I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature.
> but that the binary was built from this code
Doesn't code signing address this? If not could you explain (for my own learning)?
https://en.wikipedia.org/wiki/Code_signing
> that your operating system and every layer below it is also trustworthy.
Yep, this is the last major piece for true security in my mind. Although there is some movement in the open hardware space as well as USB mounted OSs (http://gizmodo.com/try-the-super-secure-usb-drive-os-that-ed...).
> I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
Sure...perfectly accurate...but in the context you are implying that WhatsApp is malicious. To which I think "hackuser" was interpreting as "closed source is malicious" and therefore offering open source (and by implication Signal) as an alternative.
Might just be a miscommunication moment :-)
This is not a belief that people who actually do software security audits hold. Verifying binary only software is table stakes to a security audit of a third party application as you cannot trust the source provided.
Having source is a bonus for security audits not a requirement.
No.
OpenWhisper system otherwise GPLv3 auditable libraries are closed source for usage by WhatsApp and Facebook Messenger. Either OpenWhisper systems has elected not to enforce their copyright (in which case you could make a BSD/MIT/Apache fork of their software), OR they have consented to Facebook allowing them to circumvent the license.
Eitherway. The code in WhatsApp is off limits for anyone not working with Facebook so well never know. Closed source crypto is bad. We only have WhatsApp's word the Facebook libraries have no modifications.
As far as I can tell this 'backdoor' is only relevant for the scenario where WhatsApp is not actively malicious, but gets taken over by a malicious entity, which wants to target someone who's disabled updates.
Has anyone performed such an audit?
https://play.google.com/store/apps/details?id=com.googlecode...
Can this be verified? Can this be verified to be the case 100% of the time? Is there anything stopping the client from lying to a user [0] with this interface, saying one thing (i.e. "this will not be resent") and doing another (i.e. resending)?
[0] - Or being triggered to lie to a particular user at a particular time.