New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The secret keys are stored in the clear in the databases database. #253

Closed
ThomasHabets opened this Issue Oct 10, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@ThomasHabets
Contributor

ThomasHabets commented Oct 10, 2014

Original issue 254 created by wolfkabal on 2013-03-26T20:08:34.000Z:

What steps will reproduce the problem?

  1. Open the databases database from within /data/data/com.google.android.apps.authenticator2/databases/database
  2. Query the accounts table
  3. This will list out all the registered accounts as well as the registration secret key. These keys can then be used to register the account on additional devices.

What is the expected output? What do you see instead?
I don't expect to see the actual secret key here, it should be hashed or encrypted.

What version of the product are you using? On what operating system?
v2.35 running on Android v4.2.2

Please provide any additional information below.
The general premise is that you should be keeping your device secure anyways, but this also poses a problem with backups as the database is also included in backups so the potential of separation is increased.

@ThomasHabets

This comment has been minimized.

Show comment
Hide comment
@ThomasHabets

ThomasHabets Oct 10, 2014

Contributor

Comment #1 originally posted by klyubin@google.com on 2013-03-26T20:13:29.000Z:

Thank you for your report. This is working as intended/designed.

Step # 1 assumes you have root access or have otherwise compromised the security of the Android device. Security of data stored on or processed by such devices cannot be guaranteed.

Regarding your comments about backups, this database is excluded from backup. See the above paragraph if you're referring to root-requiring backup mechanisms/tools.

Contributor

ThomasHabets commented Oct 10, 2014

Comment #1 originally posted by klyubin@google.com on 2013-03-26T20:13:29.000Z:

Thank you for your report. This is working as intended/designed.

Step # 1 assumes you have root access or have otherwise compromised the security of the Android device. Security of data stored on or processed by such devices cannot be guaranteed.

Regarding your comments about backups, this database is excluded from backup. See the above paragraph if you're referring to root-requiring backup mechanisms/tools.

@ThomasHabets

This comment has been minimized.

Show comment
Hide comment
@ThomasHabets

ThomasHabets Oct 10, 2014

Contributor

Comment #2 originally posted by geoff@ggoldman.net on 2014-01-10T16:20:57.000Z:

I understand the official Google response, however counting on just the basic permission scheme within Android seems like asking for trouble.

As the use of Authenticator proliferates beyond just Google apps (i.e. Banking, etc), it would seem prudent to further protect the database. As an example, their current issues aside, look at how RSA secures the data with their soft-token application - you're not going to get it off the system it is installed on.

To your response about root - let's assume the phone is stolen. There are ways to temporarily root a device that would allow access to the Authenticator database.

The point is, someone using Authenticator is counting on the enhanced security that it provides and as time goes on may have their entire digital/financial life protected by that application. It does not seem reasonable to rely solely on basic system security as the only method of protecting such important information.

If you were a company and were having a PCI audit and you told the auditors that while the customer credit card database was unencrypted, NO worries though, because the system is behind a firewall, has good passwords and the system ACLs will protect the data - guaranteed. Would you pass the audit? Should you pass the audit? Would you want your information handled by that process?

Security designs should ALWAYS assume something will go wrong with any layer of protection and within reason each potential failure should have some form of mitigation. I would think that having more than one robust layer to protect important information is just basic due diligence. Especially nowadays.

Thanks,

Geoff Goldman
geoff@ggoldman.net

Contributor

ThomasHabets commented Oct 10, 2014

Comment #2 originally posted by geoff@ggoldman.net on 2014-01-10T16:20:57.000Z:

I understand the official Google response, however counting on just the basic permission scheme within Android seems like asking for trouble.

As the use of Authenticator proliferates beyond just Google apps (i.e. Banking, etc), it would seem prudent to further protect the database. As an example, their current issues aside, look at how RSA secures the data with their soft-token application - you're not going to get it off the system it is installed on.

To your response about root - let's assume the phone is stolen. There are ways to temporarily root a device that would allow access to the Authenticator database.

The point is, someone using Authenticator is counting on the enhanced security that it provides and as time goes on may have their entire digital/financial life protected by that application. It does not seem reasonable to rely solely on basic system security as the only method of protecting such important information.

If you were a company and were having a PCI audit and you told the auditors that while the customer credit card database was unencrypted, NO worries though, because the system is behind a firewall, has good passwords and the system ACLs will protect the data - guaranteed. Would you pass the audit? Should you pass the audit? Would you want your information handled by that process?

Security designs should ALWAYS assume something will go wrong with any layer of protection and within reason each potential failure should have some form of mitigation. I would think that having more than one robust layer to protect important information is just basic due diligence. Especially nowadays.

Thanks,

Geoff Goldman
geoff@ggoldman.net

@ThomasHabets

This comment has been minimized.

Show comment
Hide comment
@ThomasHabets

ThomasHabets Oct 10, 2014

Contributor

Comment #3 originally posted by ienliven on 2014-09-02T21:29:03.000Z:

  • "WontFix", are you joking? seriously, get it done.
Contributor

ThomasHabets commented Oct 10, 2014

Comment #3 originally posted by ienliven on 2014-09-02T21:29:03.000Z:

  • "WontFix", are you joking? seriously, get it done.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment