Basic Password Protection principles 
Author Message
 Basic Password Protection principles

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.



Wed, 18 Jun 1902 08:00:00 GMT  
 Basic Password Protection principles

Quote:

> 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.

If you don't mind switching database technology a bit, you could use
Luxent's Apollo Database. It's actually an xBase-compatible database
which has its limitations, but it features an encryption, either on
table- or record-level. The second advantage is its easy deployment: you
just copy two dll files along with the application (which makes it a
candidate for CD-Rom-based apps).

Before starting a huge project with Apollo, you probably should consult
the website (http://www.luxent.com) and the newsgroup luxent.apollo.*
(on server news.luxent.com) to see some of the common problems that come
along with Apollo. Once you learn to build around some of the most
common traps, it is fast and secure to use.

--      Matthias
___________________________________________________________

  All SPAM sent to this address is reported and posted



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Basic Password Protection principles

2. Progrmatically creating table with password protection/referential integrity?

3. Password Protection

4. Password protection....

5. Help wanted with password protection

6. password protection

7. Password protection for Netscape

8. password protection

9. password-protection

10. Programming structure and principles

11. BASIC, VISUAL BASIC, C++, DELPHI SOFTWARE FRO CHEAP PRICE

12. Password protection ??? PROBLEM ...

 

 
Powered by phpBB® Forum Software