Both are in open status. Only years ago someone working on it seem to have posted this fix in their own comments but never fixed it.. Maybe it doesn't sell ads, but Google should be able to do a bit better..
The Android OS allows apps to protect their users by blocking other apps from screenshotting their content. This is done by adding a "FLAG_SECURE" option inside the app's configuration. Google did not add this flag to Authenticator's app, despite the fact that the app was handling some pretty sensitive content.
The question becomes WHY have they not done this. Despite being warned for years, despite it being a simple patch, it was deliberately not done.
I cut the authenticator team some slack here, because Android permissions are a complex mess. Do you feel like you understand them well enough to make your apps secure? I don't.
I DO blame the Android permissions team for this nonsense though, because they're just an ad-hoc mess, driven by feature requests, rather than fitting into any kind of rational design. A permissions system needs to be well thought out and well defined. That means a programmer using the system can understand what the various permiss
We just fucking don't. From the consumers that constantly buy and use compromised devices to the businesses that constantly produce security functions on them... you can tell a consumer that a device is not secure and they will still buy it. You can tell a business that a device is not secure and they will still fucking use it! I have personally been in such scenarios... and more than a few times.
We just do not fucking care! Compound that with the fact that most people and m
TOTP is based on HMAC, which is provably more secure than the underlying hash function. (I've had to actually do this mathematical proof lately for a post grad crypto course).
The underlying hash for Google's TOTP is the weakest TOTP version, based on SHA1. The best (fastest) attack on SHA1 is a length-extension extension attack, where the attacker chooses both messages. Of course for TOTP the attacker doesn't get to choose your secret key, but even if they did, finding an collision takes over 9,223,372,03
So if I understand correctly this is still not fixed?
iphone version:
https://github.com/google/goog... [github.com]
android version:
https://github.com/google/goog... [github.com]
Both are in open status. Only years ago someone working on it seem to have posted this fix in their own comments but never fixed it.. Maybe it doesn't sell ads, but Google should be able to do a bit better..
The Android OS allows apps to protect their users by blocking other apps from screenshotting their content. This is done by adding a "FLAG_SECURE" option inside the app's configuration.
Google did not add this flag to Authenticator's app, despite the fact that the app was handling some pretty sensitive content.
The question becomes WHY have they not done this. Despite being warned for years, despite it being a simple patch, it was deliberately not done.
I DO blame the Android permissions team for this nonsense though, because they're just an ad-hoc mess, driven by feature requests, rather than fitting into any kind of rational design. A permissions system needs to be well thought out and well defined. That means a programmer using the system can understand what the various permiss
No one Cares about Security.
We just fucking don't. From the consumers that constantly buy and use compromised devices to the businesses that constantly produce security functions on them... you can tell a consumer that a device is not secure and they will still buy it. You can tell a business that a device is not secure and they will still fucking use it! I have personally been in such scenarios... and more than a few times.
We just do not fucking care! Compound that with the fact that most people and m
TOTP is based on HMAC, which is provably more secure than the underlying hash function. (I've had to actually do this mathematical proof lately for a post grad crypto course).
The underlying hash for Google's TOTP is the weakest TOTP version, based on SHA1. The best (fastest) attack on SHA1 is a length-extension extension attack, where the attacker chooses both messages. Of course for TOTP the attacker doesn't get to choose your secret key, but even if they did, finding an collision takes over 9,223,372,03