I was poking around my GS3 today (ATT version but running the Sprint Official JB release LJ7) and I found something pretty shocking. I was poking around the S-memo databases when I opened a table using SQLIte editior. When I opened the table I was shocked to see my Google account username and password in clear plain text. Now, I did have the option to sync to Google drive and the app did prompt for my google username and password so obviously it stores it somewhere. I was just shocked to see it stored in plain text and not encrypted.

I know someone who checked his ATT GS3 running ICS and he did not have these entries in his DB which makes me think it's a JB thing.

To check you need to be rooted and have SQLite editor installed.

Steps to check
1. Set up S-Memo to sync with your Google account
2. Use SQLite editor and navigate to /data/data/com.sec.android.provider.smemo/databases
3. Open the Pen_memo.db file and select the CommonSettings table. Look to see if your Google account info is stored in plain text.

This could potentially be a serious issue. If people running JB on their GS3 can check this that would be awesome. Someone already checked the latest ICS build for the ATT variant but if others on ICS or with a different variant can check that would be great. I will get to check my GF's I-9300 running JB tomorrow when I see her.

Also I'm not sure how app permissions work on android, meaning if one app could access the data/database of another app(without root, because obviously with root another app can, in this case SQLite opened the file). Since the DB is in the /data partition and the permissions are r/w by default I'm thinking it wouldn't be difficult for a malicious non root app to access this database and query it for the information unless there is something built into android that wont allow that.

I have attached a SS of what my table looked like. Obviously I blacked out my PW and also the Google auth ID

Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.

Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.

Ahh OK. Yeah I wasn't sure if another app would be able or not. Ive never not been rooted so I wasnt 100% sure about that. So I guess this issue would just concern root users. I still think though the data should have been encrypted before the record was inserted. It did kinda freak me out to open that table and see my google password staring at me.

Actually, while /data is available for you to browse, that is because you have root. It's RW but only within the packages that each app is sandboxed. If you disable root you will not be able to view that database.

It is possible for the same developer to access the /data files of another one of their apps if they use the same namespace.

So, while this is indeed a risk, it would not be trivial for another app to gain access without asking for root or cracking root itself.

There are on Play and on the net "free apps" which needs root access to work. Once you grant access to any of them those can get your info and sent it to anyplace.

There are on Play and on the net "free apps" which needs root access to work. Once you grant access to any of them those can get your info and sent it to anyplace.

Sent from my O=O

Agreed but that is why you should be checking carefully what root apps are doing. Also not just willy-nilly granting Superuser permissions. Half of XDA would be at risk cause they see the SuperUser popup and most of the time just press grant not ever thinking 'What does that mean?' yes they want to test an app, but FFS check what it wants to do. That is the screen that pops up (another one people ignore - yes I am guilty of it my self sometimes thinking nothing has changed between one version to the next) just as you are installing the app. If it is wanting to do things in areas you don't want it to be then don't install it and confront the developer about it.

In this case you can't really confront Samsung devs about this, but the thing is we know what it is for, and secondly your not installing it comes pre-installed. But you get my point. I doubt that the Samsung devs have malicious intensions, where as other developers that your are granting SuperUser permissions to...who knows?

Yikes! Good news, this is not as bad as it seems. The data is not accessible without root.

Once an app has root, it is all over. You have to trust the app to use it wisely (trust me a lot of root apps are unsafe). With this kind of issue, it is probably safer to notify the OEM before publishing, allowing them time to fix it. This is exactly why I am not one to run root apps without a review of them myself.

I took the liberty to forward this on to those that can get it fixed. Nice find.

Agreed but that is why you should be checking carefully what root apps are doing. Also not just willy-nilly granting Superuser permissions. Half of XDA would be at risk cause they see the SuperUser popup and most of the time just press grant not ever thinking 'What does that mean?' yes they want to test an app, but FFS check what it wants to do. That is the screen that pops up (another one people ignore - yes I am guilty of it my self sometimes thinking nothing has changed between one version to the next) just as you are installing the app. If it is wanting to do things in areas you don't want it to be then don't install it and confront the developer about it.

In this case you can't really confront Samsung devs about this, but the thing is we know what it is for, and secondly your not installing it comes pre-installed. But you get my point. I doubt that the Samsung devs have malicious intensions, where as other developers that your are granting SuperUser permissions to...who knows?

Agreed with you.

But about Google's Devs, because it's a Google's flaw. Encryption is old enough, so they can implement it.

If somebody knowledgeable stole your GS3, and mounted it in Linux using adbfs, would make a bad situation worse, if they got your Google account login. Passwords in plaintext are bad in any case, I still don't trust either Android or iOS for really sensitive apps like banking.

XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.Are you a developer?