AesPrefs - Library
- 9 Antworten
- Letztes Antwortdatum
Kardroid
Stamm-User
- 154
Hallo Missspelled,
ich hätte zwei Fragen zu deine Library.
1. Warum Apache Lizenz?
2. Ist es denn deiner Meinung nach sicher? Das Passwort wird ja mit in der APK gespeichert und diese kann man ja soweit ich weiß dekompilieren.
Wenn jemand also an die sharedPreferences kommt, dann wahrscheinlich auch an die APK und den Schlüssel, und kann dann entschlüsseln und auch neue Werte verschlüsseln.
Ich wüsste jetzt auch nicht auf die schnelle, wie man es besser machen könnte, und ob man es überhaupt besser machen kann.
ich hätte zwei Fragen zu deine Library.
1. Warum Apache Lizenz?
2. Ist es denn deiner Meinung nach sicher? Das Passwort wird ja mit in der APK gespeichert und diese kann man ja soweit ich weiß dekompilieren.
Wenn jemand also an die sharedPreferences kommt, dann wahrscheinlich auch an die APK und den Schlüssel, und kann dann entschlüsseln und auch neue Werte verschlüsseln.
Ich wüsste jetzt auch nicht auf die schnelle, wie man es besser machen könnte, und ob man es überhaupt besser machen kann.
missspelled
App-Anbieter (In-App)
- 127
- Themenstarter
- #3
Hallo, vielen Dank für die Rückmeldung.
Apache, da sie meines Wissens die unproblematischste Nutzung ermöglicht. (Ich will selbst im Schadensfall nicht haften und andere können gerne den Code weiter modifizieren bzw verändern...) gibt es eine bessere Möglichkeit für mich?
Zum zweiten Punkt: Du hast vollkommen recht. Durch ein zusammenchainen oder modifizieren des PWs könnte man die Sicherheit nochmal erhöhen - oder das PW per Web-Api anfragen. Aber auch hier gilt der von dir genannte Grundsatz, dass diese Methoden keine 100%tige Sicherheit versprechen.
Vielleicht sollte ich ausdrücklicher darauf hinweisen, dass es sich lediglich um eine zusätzliche Schicht an Sicherheit handelt und nicht um "die wasserdichte Allzwecklösung". Mir selbst geht es mehr darum, nicht mehr mit einfachen Root-Apps die SharedPrefs einsehen und modifizieren zu können (und einen komfortablen Zugang hinsichtlich des Context zu den SharedPrefs zu haben).
Letztlich ist es mit mehr Arbeit verbunden die App zu decompileren (und kann in D ja auch strafrechtliche Konsequenzen mit sich bringen) als besagte Root-Apps zu missbrauchen.
[DOUBLEPOST=1440493066,1440492749][/DOUBLEPOST]Ansonsten lassen sich auch String Arrays verschlüsselt ablegen und es wird bei jedem Zugriff eine Zeitmessung gestartet (meiner Meinung nach auch noch zwei nette Gimmicks)
Apache, da sie meines Wissens die unproblematischste Nutzung ermöglicht. (Ich will selbst im Schadensfall nicht haften und andere können gerne den Code weiter modifizieren bzw verändern...) gibt es eine bessere Möglichkeit für mich?
Zum zweiten Punkt: Du hast vollkommen recht. Durch ein zusammenchainen oder modifizieren des PWs könnte man die Sicherheit nochmal erhöhen - oder das PW per Web-Api anfragen. Aber auch hier gilt der von dir genannte Grundsatz, dass diese Methoden keine 100%tige Sicherheit versprechen.
Vielleicht sollte ich ausdrücklicher darauf hinweisen, dass es sich lediglich um eine zusätzliche Schicht an Sicherheit handelt und nicht um "die wasserdichte Allzwecklösung". Mir selbst geht es mehr darum, nicht mehr mit einfachen Root-Apps die SharedPrefs einsehen und modifizieren zu können (und einen komfortablen Zugang hinsichtlich des Context zu den SharedPrefs zu haben).
Letztlich ist es mit mehr Arbeit verbunden die App zu decompileren (und kann in D ja auch strafrechtliche Konsequenzen mit sich bringen) als besagte Root-Apps zu missbrauchen.
[DOUBLEPOST=1440493066,1440492749][/DOUBLEPOST]Ansonsten lassen sich auch String Arrays verschlüsselt ablegen und es wird bei jedem Zugriff eine Zeitmessung gestartet (meiner Meinung nach auch noch zwei nette Gimmicks)
Jaiel
Dauer-User
- 235
Ich würde auch vorschlagen eine 1024 Bit oder 2048 bit RSA verschlüsselung darüber zu legen.
missspelled
App-Anbieter (In-App)
- 127
- Themenstarter
- #5
Nope, aus 2 Gründen...
1. RSA ist asymetrisch und deswegen hier nicht geeignet. Wüsste jedenfalls nicht wie man es für obigen Verwendungszweck sinnvoll nutzen sollte.
2. AES256 gilt als zugelassen für Dokumente der höchsten Geheimhaltungsstufe in US-Behörden.
1. RSA ist asymetrisch und deswegen hier nicht geeignet. Wüsste jedenfalls nicht wie man es für obigen Verwendungszweck sinnvoll nutzen sollte.
2. AES256 gilt als zugelassen für Dokumente der höchsten Geheimhaltungsstufe in US-Behörden.
Kardroid
Stamm-User
- 154
@missspelled: Ich finde eine MIT-Lizenz für den Librarybenutzer besser.
Bei Apache muss man noch irgendwas beachten. (Ich habe jetzt vergessen, was
)
Deine Begründungen finde ich auch gut und nachvollziehbar. Wenn ich SharedPreferences benutzen sollte, die nicht so leicht zu lesen sein sollen, dann werde ich deine Library benutzen.
Bei Apache muss man noch irgendwas beachten. (Ich habe jetzt vergessen, was
)Deine Begründungen finde ich auch gut und nachvollziehbar. Wenn ich SharedPreferences benutzen sollte, die nicht so leicht zu lesen sein sollen, dann werde ich deine Library benutzen.
D
deek
Stamm-User
- 395
Dann mal ein paar Anmerkungen von mir:
- Du hast in deiner lib eine strings.xml mit einem app_name drin. Für eine lib eher unnötig und kontraproduktiv (vgl http://droidcon.de/sites/droidcon.d...ymond Chenon-app fails and retrospectives.pdf ab Slide 16)
- warum überhaupt eine aar und nicht eine einfache jar? Du hast keinerlei sonstige Resourcen dadrin, also ist aar unnötig.
- Die Kür zur Erhöhung der Sicherheit wäre ein Beispiel für ein Stück native Code (und eine passende API das einfach zu benutzen) in dem das Password reinkompiliert ist. Das wäre deutlich schwerer zu decompilieren als der reine java Code der apk.
Ansonsten überlege ich gerade ein Plugin für esperandro dafür zu bauen. (dkunzler/esperandro · GitHub
- Du hast in deiner lib eine strings.xml mit einem app_name drin. Für eine lib eher unnötig und kontraproduktiv (vgl http://droidcon.de/sites/droidcon.d...ymond Chenon-app fails and retrospectives.pdf ab Slide 16)
- warum überhaupt eine aar und nicht eine einfache jar? Du hast keinerlei sonstige Resourcen dadrin, also ist aar unnötig.
- Die Kür zur Erhöhung der Sicherheit wäre ein Beispiel für ein Stück native Code (und eine passende API das einfach zu benutzen) in dem das Password reinkompiliert ist. Das wäre deutlich schwerer zu decompilieren als der reine java Code der apk.
Ansonsten überlege ich gerade ein Plugin für esperandro dafür zu bauen. (dkunzler/esperandro · GitHub
missspelled
App-Anbieter (In-App)
- 127
- Themenstarter
- #8
@deek: Danke für die Hinweise. Werde ich bei künftigen Builds berücksichtigen.
Für die aar habe ich mich entschieden, da ich die Idee vom Android-Archive sehr ansprechend finde (auch wenn es in der heutigen Form der Lib definitiv nicht nötig wäre, vollkommen richtig..).
Mit nativem Code für Android-Code habe ich mich bis dato noch nicht näher beschäftigt, aber werde ich auch mal in Angriff nehmen - kennst du hier einen guten "Einstiegspunkt" in die Materie? Bisher scheiterte es in der Vergangenheit etwas daran, dass ich zwar angefangen habe nachzulesen "wofür" und "wie", mir dann letztlich aber immer der Überblick und somit auch (recht schnell) das Interesse gefehlt hat mich mit dem Thema weiter zu beschäftigen.
Für die aar habe ich mich entschieden, da ich die Idee vom Android-Archive sehr ansprechend finde (auch wenn es in der heutigen Form der Lib definitiv nicht nötig wäre, vollkommen richtig..).
Mit nativem Code für Android-Code habe ich mich bis dato noch nicht näher beschäftigt, aber werde ich auch mal in Angriff nehmen - kennst du hier einen guten "Einstiegspunkt" in die Materie? Bisher scheiterte es in der Vergangenheit etwas daran, dass ich zwar angefangen habe nachzulesen "wofür" und "wie", mir dann letztlich aber immer der Überblick und somit auch (recht schnell) das Interesse gefehlt hat mich mit dem Thema weiter zu beschäftigen.
I
{I-love-Android}
Ambitioniertes Mitglied
- 5
Hey, wirklich super die SharedPreferences zu verschlüsseln... Mich nervt es immer extrem wenn die von Apps wie "Hack App Data" einfach modifiziert werden können... Muss ich mir später nochmal genauer anschauen wie sie funktioniert aber wirklich super Idee...
D
deek
Stamm-User
- 395
missspelled schrieb:
Leider nein. Für solche kleinen Sicherheitsfeatures fände ich es für mich auch sehr interessant, deshalb habe ich gehofft von dir ein schönes Beispiel zu bekommen
Eventuell machen wir sowas demnächst mal hier in der Firma (allerdings Java und auf Windows, da wird man noch etwas abstrahieren müssen), dann kann ich vielleicht was sinnvolles beisteuern.
Hast du dir eigentlich mal die anderen Projekte angeschaut, die es in dieser Richtung gibt?
scottyab/secure-preferences · GitHub
chrisjenx/android-secure-preferences · GitHub