|
|
Basic Password Protection principles
| Author |
Message |
|
Vasilis Stergioul
#1 / 6
|
 Basic Password Protection principles
Quote:
>Basic Password Protection principles
See http://www.*-*-*.com/
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
|
Sundial Service
#2 / 6
|
Basic Password Protection principles Quote:
> Basic Password Protection principles
> 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.
First of all, forget systems such as Paradox/BDE table encryption. You
will need a system that "strongly" protects the information
(cryptographically) while allowing for acceptable encryption and
decryption times. I would not consider -any- "home grown" algorithm for
this purpose; there are plenty of good ones on the web.
Be aware that many of the better algorithms are patented or otherwise
licensed, and be aware of the (rather peculiar) export control laws of
the United States.
You could delay any ACL-modification by encrypting the ACL file and
loading the plaintext with checksums and CRCs. Any modification to the
ciphertext, even one byte of it with a good encryption-system, should
completely destroy the plaintext.
The challenge in such a system would be to adequately protect the
encryption-keys that your application, ultimately, must acquire and use
to decrypt the contents. And to make the algorithm that recovers the
keys sufficiently difficult to find. A large key-file with
mostly-random data in it could conceal a key using a stenographic
technique.
But ultimately, when you put "secure" information into a desktop
environment, it won't be very secure any more.
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Tang
#3 / 6
|
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. Normally Id just store a table with a list of encrypted
why don't you just use a security table, where your table is securd
with a password. That's simple, fast and effective.
I use a .mdb table where I have to access it with a password which is
hard coded in the. exe file. The program can get into it, but the user
can't.
Flavio
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Alexander T. Petrus
#4 / 6
|
Basic Password Protection principles Quote:
> Basic Password Protection principles > 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.
How about creating a hidden table, somewhere else than the directory in which
your program will be installed?Eventually you can create a mirror table that can
compare datas.
Not to mention that you could give management rights to only one or two persons,
with access levels.
Only those persons could then create new users. Kind of NT user rights.
Quote: > 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.
> Thanks,
> David Lederman
--
Alexander T. Petrusa
The one who is not ready today, will be less ready tomorrow...
(514) 856-3060
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Sundial Service
#5 / 6
|
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. Normally Id just store a table with a list of encrypted
> why don't you just use a security table, where your table is securd
> with a password. That's simple, fast and effective.
> I use a .mdb table where I have to access it with a password which is
> hard coded in the. exe file. The program can get into it, but the user
> can't.
Well, Tango, it depends upon what kind of security the data requires.
Paradox tables have serious security-holes including "magic big-kahuna
passwords" that have no business being there -- but that you can find
with an afternoon's search through the Internet. It sounds to me like
the original poster was worried about some fairly sophisticated attacks
being mounted against the data, which sounded highly proprietary (like
medical records).
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Mic
#6 / 6
|
Basic Password Protection principles
Quote:
>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.
You'd have to make the above impossible to do. Hide a password in that
file which u can use to en/decrypt the records, and which only is used
when a login is correct, and which has to be set at initialization. In
that case security is a matter of the desktop-"administrator".
For full security you'd even blank the -in this process- used
memoryspace before disposal.
Mick
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
| |
|
