Join GitHub today
Vulnerability: hard coded password for Android KeyStore #55
For Android: instead of using a hard coded KeyStore password, the application should provide its own from a safe origin (the app should be responsible for coming up with a password).
Otherwise the Xamarin.Social.Accounts keystone in all apps that use the Xamarin.Auth components can be easily breached by just looking at the source code on GitHub.
I'll provide a PR in which I add the option to provide your own password. Ideally the hard coded pwd should be taken out, but I'll leave it in for backwards compatibility.
Thanks guys. So what's the work around for the hardcoded password? do i need to prompt the user for input? Opened this topic in http://stackoverflow.com/questions/38234603/xamarin-android-secure-strorage-keystore
Will be happy to post any updates once this is resolved.
Has this been solved or not?
I am rather confused on this because:
After looking into the code on the branch that looks to be the latest, I see that there's still the password, but I believe it is only used to migrate from the old password to the new one old clients. Is that the case?
Just to help people following my path in the future, could you:
True. Initial code was written with security bug. It was fixed in March/April and published as nuget.
One of the nuget.org problem is that there is no verification process, so anybody can submit Xamarin.Auth package. The version 1.2.2 is not listed here:
True. This was experimental Windows Phone branch. In the meantime several Windows Platforms have been added, even UWP. The problem is that the whole publishing goes through CI servers and there were issues with UWP builds. Additionally merging hardware with Microsoft added some delay into the process.
True. It is obvious as windows-phone-experimental. We are still working on it. If you clone/checkout those you will see a lot of changes. For a lot of bugfixes we never got feedback.
Exactly. Yes there are some bugs in the code and we try to maintain backward compatibility.
There is 2 approaches: close-n-dont-care or leave-it-open-until-someone-confirms-it-is-solved.
According to semantic versioning used by nuget 1.3.1-* comes before 1.3.1 and thus 126.96.36.199.
We are working on it.
If you read carefully this thread you will see there was commit with bug fix and the first nuget alpha version was 1.3.1-alpha-01.
The commit where this was changed was:
and the nuget with that fix was packaged and pushed in this commit (mentioned in this thread):
The only problem is that this issue was not closed (yet).