[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] System Functional Requirements
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] System Functional Requirements |
Date: |
Tue, 22 Mar 2016 10:58:46 +0100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
Hello Holger,
your response is more directly to the point. I agree that we
agree that privacy concerns cannot be taken lightly in
healthcare.
> I think what Alejandro was looking for was what normally is supposed to some
> sort of security classification.
I did not understand what he was looking for. That's why I
asked whether he would like to elaborate.
> Besides: I would strongly disagree with your statement, that timeouts are the
> job of higher layers.
I expressed my opinion on those two examples, not on timeouts in general.
> Within my regular job, this kind of data would be ranked
> into highes security customer data, which would imply, that
> any system storing or using this data would need to use
> encryption for data storage,
I agree. That's the job of PostgreSQL or the filesystem (IMO
the latter).
> at least one way encryption for passwords,
Passwords are encrypted by PostgreSQL.
> two factor authentication for admins
PostgreSQL can be set up for two factor.
> and definitely timeouts for userlogins within the
> application to make sure, that no data can be viewed by any
> person without permission.
What is the exact difference between a screen locker that
kicks in after one minute and an application lock that kicks
in after one minute ?
I am pretty sure you aren't suggesting that I individually
unlock all 4 applications I have running alongside ? A
desktop session lock would lock/unlock all 4 at the same
time, some of which I may not even have control over due to
them being proprietary.
> But I know that most of the times the developers simply
> fail in offering these people the tools they need to have
> to implement these security levels in a usable way.
I am sure Alejandro could elaborate on - if he so wishes -
which threats he wishes to mitigate. Define the threat
scenario, identify the attack surface, look for the tools --
fine with me.
> What I saw lately as a good example was some sort usb-token
> for every waiter. Without a key, the terminals were locked,
> inserting and some sort of 4 character pin unlocked the
> terminal „app“.
This can be done with a pam_usb enabled desktop session
locker (say, screensaver).
> I know of some people using ubikey for this kind of 2
> factor auth, some are using google authenticator, which i
> would not find usable here, but sure there are more of these
> possibilities.
> This is, what I would like to see at a doctors place...
Sure, and they should be implemented at the desktop session level.
This is _not_ to say the application level should _not_ offer
any security measures.
And, BTW, this is FLOSS so patches are welcome and forks
possible.
$> grep -H -n -A 10 'def _on_user_activity_timer'
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py:3517: def
_on_user_activity_timer_expired(self, cookie=None):
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3518-
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3519-
if self.user_activity_detected:
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3520-
self.elapsed_inactivity_slices = 0
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3521-
self.user_activity_detected = False
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3522-
self.elapsed_inactivity_slices += 1
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3523-
else:
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3524-
if self.elapsed_inactivity_slices >= self.max_user_inactivity_slices:
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3525-#
print("User was inactive for 30 seconds.")
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3526-
pass
Projekte/gm-git/gnumed/gnumed/client/wxpython/gmGuiMain.py-3527-
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- [Gnumed-devel] System Functional Requirements, Alejandro Velasco Dimate, 2016/03/18
- Re: [Gnumed-devel] System Functional Requirements, Karsten Hilbert, 2016/03/19
- Re: [Gnumed-devel] System Functional Requirements, Alejandro Velasco Dimate, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Karsten Hilbert, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Karsten Hilbert, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Alejandro Velasco Dimate, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Karsten Hilbert, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Alejandro Velasco Dimate, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Karsten Hilbert, 2016/03/20
- Re: [Gnumed-devel] System Functional Requirements, Holger Patzelt, 2016/03/21
- Re: [Gnumed-devel] System Functional Requirements,
Karsten Hilbert <=