Hello,
Big problem, but basic (!!) & simples possibilities giving a security
depending of crypting algorithm you use
suppose you have a dedicated password table, a simple paradox table, or what
you want (registry,.may be better..)
for example : Login A(20) / PswdCrypt A(20) / RightsCrypt0 A(..) /
RightsCrypt A(...)
You need first two crypt/decrypt function with the algorithm you want,
The problem first is to associate a login with a password and with rights to
do anything
one solution is
- crypt the password using (partially ?) login, to dont have possibility of
copy between two login
PswdCrypt := Crypt( 'Password', CryptingParameters...) ;
// with CryptingParameters using Login + secret internal
// (2 identical password, not giving same crypted password, because
Login is different)
- crypt the login + right's accesses (no copy of rights possibles, cause
login auto-identify and change ),
RightsCrypt := Crypt( Login + Data1 + Rights ,
CryptingParameters...); // protection against direct changes
RightsCrypt0 := Crypt( Login + Data0 + Rights, CryptingParameters
...);
// Data0-1 are internal to shuffle all, the crypting algorithm has to
do anything different
// in fact, Data0-1 may be incorporated inside Crypting parameters
// essential is : it is impossible to directly do from RightsCrypt to
RightsCrypt0 without knowing Rigths (or decrypt...)
- you have to remenber to change the 2nd one when the user change his pswd,
or when rigths change
and verify Login inside before affect rights
StringToVerify := Decrypt( RightsCrypt, DeCryptingParameters...); //
with DeCryptingParameters using Login
- verify existence of Login in start of StringToVerify
LoginToVerify := Copy(StringToVerify, 1, LoginLength);
if Login = LoginToVerify
then Rights := Copy(StringToVerify,LoginLenth + 1,RightsLenth)
else ... Alarm !!! or one more try,...and count for ...
- verify Rights not to have been changed from internal manner by comparison
between Decrypt(RightsCrypt0,...) and Decrypt(RightsCrypt,...)
// and now you can access what is corresponding to your rights, for
example, do 'visible' what is corresponding to rights...or true the
queries...(take attention to pre-calculate queries), or decrypt where you
have rights on....(crypting data using internal crypting, each parameter can
be different...) you can use multi-step crypt ...
//
Nb : if you are not concerned to mask rights's people to others (why he and
not me !!) , it's not necessary to have Rightscrypt0, you can use directly
Rights
if you want a protection against insertion / deletion of records
- you have to add an other record using a checksum (or anything like this)
on logins and number of records, and protect this checksum by the same
manner with association with crypted checksum (checksum is like another
login...)
because of that, a record can't be changed, inserted or deleted without
application stops
(the first thing to test at beginning, is that there is no problem..., and
re-test when you do rights, change people,...
any action of an intruder will stop the application
if you want not the Login to be knowed, crypt it using itself (crypting
parameters have to use Login !!!!, or anything using Login)
CryptLogin := Crypt(Login, CryptingParameters,..)
- you have to do an interface to do rights to others (administration)
- you can do... more and more, security is only by combinationn of several
actions (if possible not trivial...)
***** But, if you are using very confidential information,
******you HAVE to use a real OS with security inside, and a security managed
DataBase-
JEL Consultants
Quote:
>Basic Password Protection principles
>Hi, for years Ive worked on large C/S projects were security was handled
>either as pass-through system (using SQL Server/NT Server built-in
security)
>or using a security table. This never presented a problem because either
way
>only administrators had the proper rights to view the data or change the
>ACL.
>A new project Im working is a desktop based program. All the data and
files
>will reside on the clients machine. This causes a problem because security
>is required. Normally Id just store a table with a list of encrypted
>passwords. But this way a user can just go in and delete the record, or
>create a new user and copy the encrypted password to the other user. So I
>considered a normal file with garbage information and user names and
>passwords, which are encrypted, (which makes it hard to scan for the user
>name) encrypted passwords. But then a user needs just install the program
to
>a separate folder and copy the {*filter*} security file and viola they have
>security privileges.
>Basically I would like if any one can send me their comments/ideas on
>providing strong security in an naturally unsecured environment.
>Thanks,
>David Lederman
>PS.
>In advance I apoligize for cross posting, I just want to get the broadest
>range of comments.
Basic Password Protection principles