user authorization (with one time login) in a Python desktopapplication ?

[Stef Mientki]

hello,

I've a Python desktop application, running under Widows, that stores the
data in a central SQLite database.

Depending on the user login on the system, some of the data from the
database is allowed and other data is forbidden.

I can read the current logged in user.
The authorization for each user is stored encrypted in the database.
The program is delivered as pyc files,
but from what I read, these can easily be reversed engineered.

There is even an encrypted version of SQLite (not freeware),
but as long as test the authorization in Python,
it doesn't seem to be a good protection.

So at first thought, a better way might be the following process:
- encrypt the whole database
- run all queries through a DLL written in C or Delphi, where also the
authorization is checked

But on second thought that isn't true.
The login on the computer is assumed to be enough (1-time login).
So the Python program passes the username to the external DLL.
And there's the weak point again,
the username of every person in our organization is known to every one.
So it shouldn't be too difficult to modify the program,
so it will always use the external DLL with the username with the
highest authorization.

So the question remains:
Is it possible to create a Python Desktop application,
with user authorization, based on the login of the user ?

thanks,
Stef Mientki

 

[Steven D'Aprano]

hello,

I've a Python desktop application, running under Widows, that stores the
data in a central SQLite database.

Depending on the user login on the system, some of the data from the
database is allowed and other data is forbidden.

I can read the current logged in user. The authorization for each user
is stored encrypted in the database. The program is delivered as pyc
files, but from what I read, these can easily be reversed engineered.

What does that have to do with anything? You're not storing the user's
password in the source code are you?

There is even an encrypted version of SQLite (not freeware), but as long
as test the authorization in Python, it doesn't seem to be a good
protection.

What exactly are you doing to authenticate the user?

So at first thought, a better way might be the following process: -
encrypt the whole database

What is your threat model? What are you trying to protect against?

If your threat model is that desktop users will sneak into the server
room while the boss is away, boot the server in single-user mode, and
then use a disk utility to inspect the raw bytes on disk to read the data
in the database (or that the government will swoop in and seize your
computer and do the same), then encrypting the entire database may be a
good idea.

(But if your threat model is the government, then what are you going to
do when they arrest you and demand you hand over the encryption keys?)

But if your threat model is that Fred will guess Barney's password, then
encrypting the entire database is a waste of time. All it does is make
your job harder, and the application slower, and it accomplishes nothing
to stop Fred guessing the password.

Rather than trying to invent your own scheme for authentication, I
suggest you see how your database handles it. Chances are this is already
a solved problem. If SQLite doesn't handle authentication, there are
plenty of "real" databases that do.

- run all queries through a DLL written in C or Delphi, where also the
authorization is checked

But on second thought that isn't true. The login on the computer is
assumed to be enough (1-time login). So the Python program passes the
username to the external DLL. And there's the weak point again,
the username of every person in our organization is known to every one.

If you can't trust the users not to swap usernames and passwords, you
can't stop users from logging in as somebody else. Writing your
application in C or Delphi can't prevent that. (I suppose you could use
biometrics, but then what's to stop Fred calling Barney and getting him
to put his thumb on the thumbprint reader?)

You need to think carefully about what threat you are defending against.
Who is the enemy? Who can you trust? What *exactly* are you trying to
stop them from doing?

So it shouldn't be too difficult to modify the program, so it will
always use the external DLL with the username with the highest
authorization.

So the question remains:
Is it possible to create a Python Desktop application, with user
authorization, based on the login of the user ?

Are you trying to integrate that with the user's Windows login? That will
probably be hard.

 

[Tim Golden]

What is your threat model? What are you trying to protect against?

[... snip further stuff from Stephen, usefully requiring
clarification if ideas from the OP ...]

As a general rule within Windows, you let Windows do the
authentication for you and you base your authorisation on
the presence or otherwise of certain security groups in
user's token. You can get hold of the token via -- in
Python -- the win32security module, whose functionality
you can supplement if needed by using the ctypes model
to map in API functions which aren't already exposed.

The kind of thing you might do here -- altho' it obviously
depends on your particular situation -- would be to store
a security group's identifier (name or SID) in some sort
of roles-or-permissions table, requiring that to perform
function X, the user must be in group Y. A logged on user
either is or isn't in that group.

Obviously, as was pointed out, if your users are so
untrustworthy, they might steal or guess each other's
logon details, but at that point you've got problems far
more serious than merely the data your sqlite database
represents.

TJG

 

[Tim Golden]

Steven D'Aprano wrote:

[... snip further stuff from Stephen

whose name I can't even copy from three lines above
Sorry, Steven.

TJG

 

[Rüdiger Ranft]

By making use of the one time login on windows,
I'm not sure, but I guess the user environment variable "USER" should
hold the vald user,
which has probably a one-to-one relation with the SID

Environment variables are *very* easy to forge. But since you use
windows, you can let windows do all the security stuff for you. Since u
use sqlite, I guess that the database is stored on a file on a disk. You
can use the file permission to give access only to the users permitted
to access the file.

But when you want to separate access at dataset/column/row level, then
sqlite is not the best tool, since every user can open the database file
with an other sqlite tool. Encryption will only take more time for rogue
users, since the key needs to be stored in your application, and can be
read by the user. I would recommend a "real" database server in this
case, so the permission checks are out of the reach of the users. When u
have a kerberos or active directory environment, some servers even can
use kerberos to get the user name from the client.

bye
Rudi