[Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

임범진 bj.im at samsung.com
Thu Mar 20 09:42:42 GMT 2014


User password can be getting complicated if we consider Enterprise supprot.Many
MDM vendors mandates various password requirements. I don't have full list but I
remember some of them as follows. (All remotely configurable)
- Force set/reset
- Setup/Change password expiration
- Maximum # of retry --> if reaches phone will be locked. (should be configurable)
- Not allowing reuse previous passwords (# of history should be configurable)
- Password strength check

So, our user authenticator should be somehow flexible :)

Bumjin

-- May the Force be with you ---------------------------------------------------- 
* BumJin Im
* Senior Engineer,  Mobile S/W Platform lab, S/W Platform Team
   Samsung Electronics
---------------------------------------------------------------------------------




------- Original Message -------
Sender : Jussi Laako<jussi.laako at linux.intel.com>
Date : 2014-03-20 18:29 (GMT+09:00)
Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

On 20.3.2014 1:57, Bumjin Im wrote:
> Now I think we need to consider login manager which I didn't thought yet.

I just integrated 0.0.2 version of TLM and as the version number 
indicates, it is still early version, but eventually it would hopefully 
address the needs on Tizen. There's also a preliminary NFC plugin (not 
built yet in Tizen, needs more packages).

One way we were thinking of is to use gsignond for secondary key storage 
layer and then to just have a master key in /etc/shadow. 
Passphrase/tag/fob decrypts a master key that is then sent to PAM for 
login authentication. Or alternatively write a PAM plugin that talks to 
gsignond.

gsignond can be easily used much like a smart card device. One way is to 
use X.509 and then system uses a local symmetric key (equivalent of PIN) 
to decrypt X.509 private key on NFC tag which can then be used to sign a 
challenge to be verified against locally stored X.509 public key (cert). 
This way private key is not stored on the system while the private key 
on the NFC can only be read by the system it belongs to. It also allows 
other uses of the X.509 such as S/MIME or purchases.

Or alternatively use a stack of encrypted key files.


More information about the Dev mailing list