Thread Tools
Posts: 225 | Thanked: 501 times | Joined on Aug 2011 @ suncity
Originally Posted by juiceme View Post
So it hashes the password and saves the hash to a file.
Does the authentication phase then compare a hashed input password against the hash in the file?

What prevents a malicious user to create a hash for a password, replace the hash in file and log in with the new password?
Yes, it saves the hash;
yes, it compares the inputted text/password as hash to the stored hashed password.

I was thinking about protecting the password file itself somehow but not yet implemented any solution for that.
But... even if a malicious user would create a new password even password protection can be removed by hand so the original user/owner can access to the database (frankly saying, even the database should be secured; maybe I shall try that too but need some learning on how to secure sqlite3 databases. MySQL does that 'out of the box' but that would be a big dependency to be installed...)... It is not a super-secure system yet but I'm not an expert on this field but trying to find solutions for these problems/ideas... So thanks for the suggestion I will try to implement your observations!


EDIT:// I did some experiment just out of couriousity:
- manually modifiying the password file will result that password always will be incorrect, even if the correct text/letter would be typed back;
- if I do the following from shell:
echo 'new_password_as_hashed_text' > password
then the password will be incorrect even if the correct text is typed at authentication;
- if a new password is set from under python on the device itself (or maybe generated in python on an other system and copied to the appropriate location) then it will work.

Last edited by justmemory; 2017-04-07 at 09:06.

The Following User Says Thank You to justmemory For This Useful Post:
Community Council | Posts: 4,179 | Thanked: 10,123 times | Joined on May 2012 @ Southerrn Finland
There are good ways to do it, for example use aes to encrypt/decrypt the data on the fly, only ever storing encrypted data in db.

The Following 2 Users Say Thank You to juiceme For This Useful Post:
Community Council | Posts: 536 | Thanked: 770 times | Joined on Sep 2010 @ Mbabane
Originally Posted by justmemory View Post
Please note that I'm not a programmer it is just a hobby for me
The code looks amazing to me

The Following 2 Users Say Thank You to sicelo For This Useful Post:
Posts: 225 | Thanked: 501 times | Joined on Aug 2011 @ suncity
Hi All!

I made some improvements again and hopefully you will find these useful.

So, I was thinking about protecting the financial data and of course the protection of the database appeared to be the best idea.
For this purpose I found that sqlcipher would do the trick, it has a python binding and would not have to use encryption-decryption on the fly as sqlcipher uses "pragma key".
I dropped the previous password protection method as user have to enter the key at startup of the application. The key does not stored anywhere (except the default key - "temporary_key" - when creating new database at first time running the app) in the app it "appears" only when running the app and it asks for it directly so I did not even use hashlib as I think it is not necesseary.

The "main" (?) sqlcipher I found on github did not work on arm, so I searched and found a version for Android which I used to build my own with checkinstall. The installation won't overwrite sqlite3 it just creates sqlite3 executable in /usr/local/bin and that comes default.

For pysqlcipher I used version 2.6.3; this will be "installed" as well.

From now on you can find this on GitHub.


Last edited by justmemory; 2018-01-03 at 22:22. Reason: Corrected information about sqlite3 and added GitHub link instead of google drive.

The Following 2 Users Say Thank You to justmemory For This Useful Post:

maemo 5, python-hildon

Thread Tools

Forum Jump

All times are GMT. The time now is 02:17.