Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Password Protecting A Table

Status
Not open for further replies.

Shanachie

Programmer
Jun 18, 2000
92
US
How can I restrict access to a table? The table involved is the users' signon and password list. I don't want the users to get at it, obviously, even through Excel or whatever.

Suggestions?

Shanachie
 
Hi, Shanachie!

It is very good question. You cannot. Any hacker may hack into that table and see all passwords.

However, you may solve this problem by another way, from inside of application. The aproach is quite simple. Encode password and save it encoded in the databse! More, encode it by such way that noone can decode it anymore. That approach is used in most operation systems. How to use such encoded password? In logon process user enters password. You can encode entered string too and than compare to the encoded string stored in table. If it matches - password correct - login granted.



Vlad Grynchyshyn
vgryn@softserve.lviv.ua
The professional level of programmer could be determined by level of stupidity of his/her bugs
 
Nothing native to VFP will help you.

There are a variety encriptions routines you could use on each field. I sure there are 3rd party tools you could buy.

On thing I have used is EncryptIt() Decryptit() routine. This is not a particularly speedy way to do it. An requires some coding on your part, but it does work.
Basically your table would have to be all character fields

cEncryptedValue = tableX.fieldX
cValue = DecryptIT(cEncryptedValue)

Function EncryptIT
Parameter Pword
*init vars
myCoded = ""
myPcode = ""
*encrypt it
*first convert to ascii width 3
FOR myCount = 1 to len(alltrim(Pword))
myAscii = ALLTRIM(STR(asc(substr(Pword,myCount,1))))
IF len(MyAscii) < 3 then
myAscii = Substr(&quot;000&quot;,1,3-Len(myAscii))+MyAscii
ENDIF
myPcode = myPcode+myAscii
NEXT myCount
*Next convert to ascii again
FOR mycount = 1 TO LEN(myPcode)
myCoded = myCoded + CHR(VAL(substr(myPcode,myCount,1)))
NEXT myCount
Return Mycoded

Function DecryptIT
Parameters myCoded
*decrypt it
*init vars
myPCode = &quot;&quot;
myUncoded = &quot;&quot;
*First Convert back to ascii width 3
FOR mycount = 1 TO LEN(myCoded)
myPcode = myPcode + ALLTRIM(STR(ASC(substr(myCoded,myCount,1))))
NEXT myCount
*Now Convert back to text
For myCount = 1 to Len(myPcode) STEP +3
myUncoded = MyUncoded+chr(val(substr(myPcode,Mycount,3)))
NEXT myCount
RETURN MyUncoded


-Pete
 
Pete, any hacker can get decryption program and use it over existing data to get passwords. Good approach to do not leave any of such holes. Better encrypt password entered by user and than compare it to encrypted string in database. By such way you have only encryption program, so hacker have a lot of work to do to decrypt password or find it by picking up way.

Vlad Grynchyshyn
vgryn@softserve.lviv.ua
The professional level of programmer could be determined by level of stupidity of his/her bugs
 
I agree Vlad. The functions above can be used that way. Assuming the table data is encypted. The program reads encrytped table data. It is merely a matter of sequence then.

bCheckit = False
cUserEnteredValue = what ever user enterred
cUserEncytpedValue = EncryptIT(cUserEnteredValue)
cCheckValue = encryptedTable.FieldX
IF cCheckValue == cUserEncytpedValue THEN
bCheckit = True
ENDIF




-Pete
 
Shanachie, -As it was pointed out above, If the application needs to open a table, then anyone with rights to run the application and with a word processing program can open it. You can not stop that. But you can make it hard for them find it , get to it and read. You can even change the header so even foxpro can not open it if you want.

FoxPro will read files from a Hidden Directory with the hidden attributes set on.
My trick is to place the file you do not want any one to find on a different server or even on a different partition on the servers hard drive. Group rights are set on the directory to further control access. The hidden Server/directory/file name can be hard coded into the program so noone can find it or encripted in a different table. At the start of the program I open the Hidden file read what I need from it into memory variables and then close the table and never opened it again in the application.
Also you can not set a path to the hidden directory an just say use SPECIALDBF you have to do a use &quot;\\SecretServer\SecretHardDrive\HiddenDir\HiddenFile alias xxx ... David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644
 
The world's most lightweight VFP encryption routine: (-:

PROCEDURE ENCRYPT
LPARAMETERS tcStr

lcTrnStr=''

FOR x=255 TO 1 STEP -1
lcTrnStr=lcTrnStr+CHR(x)
ENDFOR

lcRetStr = SYS(15,lcTrnStr,tcStr)

RETURN lcRetStr
ENDPROC

Also, if you are storing encrypted passwords in your table, do not permit empty passwords in your application. If the user's password in the table is blank, present a message telling them 'Access denied. Please contact system administrator.'. This will prevent them from deleting the password in the table and gaining access into your application with a blank password.

Hopefully, the introduction of database events in VFP7 might help address this type of problem. Jon Hawkins
jonscott8@yahoo.com

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed
 
Hi
Since I am a new member, I am just going thru all the tips and questions. I felt I could pass on this tip to you, if this is of any help to you.

I always store SYS(2007,passwordEntered) as the password in the database. Whenever the usesr login with their password, I convert the entered password to
passvalue = SYS(2007,enteredPassword)
if passvalue = stored password
permit
else
check-user-out
endif

This way the passwords are never stored in the database directly and no ordinary user can break it either.

Hope this is useful to you :)

ramani_g@yahoo.com
 
I've just picked up on this thread and thought I would mention that the way I check who is trying to use my system is through the Registry.

(When somone logs on to the network, they obviously have to enter a password. I'd assume that the program(s) that control network access have better security than I could program, at least without wasting time.)

So, my program then looks at

HKEY_LOCAL_MACHINE,[Network\Logon])

for the user's name and

HKEY_LOCAL_MACHINE,[System\CurrentControlSet\control\ComputerName\ComputerName])

for the user's computer name. So nowhere do I keep passwords, thus preventing anyone from seeing them. This also provides a double security against external hacking because the computer name has to match as well.

Hope this helps,

Stewart
 
Well, its reliable approach, but not so much. Just try following routine and you will see how many different strings return the same value of the check sum (TestReport table).

Code:
if used('TestData')
	use in TestData
endif
if file('TestData.dbf')
	erase 'TestData.dbf'
endif
create table TestReport (StringVal C(10))

create table TestData (CheckSum I)
use TestData
index on CheckSum tag CheckSum

local lnCheck
for i=32 to 126
	for j=32 to 126
		for k=32 to 126
			for l=32 to 126
				lnCheck = val(sys(2007,chr(i)+chr(j)+chr(k)+chr(l)))
				if seek(lnCheck)
					insert into TestReport values(chr(i)+chr(j)+chr(k)+chr(l))
				else
					insert into TestData values(lnCheck)
				endif
			endfor
		endfor
	endfor
endfor


Vlad Grynchyshyn
vgryn@softserve.lviv.ua
The professional level of programmer could be determined by level of stupidity of his/her bugs
 
Just to reinforce Vlad's comments, AFAIK, the checksum returned by SYS(2007) is only a 16-bit CRC. Therefore, as Vlad's test illustrates, the maximum number of possible unique values is 2^16 (64K).

If you are looking for a higher level of uniqueness, I'd recommend you see the following 32-bit CRC by Josh Assing:

Like I mentioned, it's produces a 32-bit CRC and therefore, as many as over 4 Billion (2^32) unique values are possible.

I've also ran some testing (similar to Vlad's above) with over 850K different strings and Josh's class returned no duplicated CRC values. Jon Hawkins

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed
 
RE: Checksums: Given that many passwords would generate any given checksum, couldn't you work backwards? If you know the answer, couldn't you construct a password that generates that checksum? How hard would it be to generate a password that has that specific checksum?

BTW, the people that use the system that I'm building aren't sophisticated enough to do any of that. They just MIGHT figure out that they can access the user table through Excel (hence encrypting the passwords) but decrypting is way beyond their reach.

It's still fun to think about.

Shanachie
 
Hi my friends,
Really interesting subject for research, I appreciate all the efforts you guys did to come up with encryption techniques, but as you may already know Windows NT maintain the C2 security level defined by the United States Department Of Defense, it means the Cryptography technology it uses is really state of the art.
The corner stone of this technology is the RSA is a public-key encryption algorithm, the most basic level of this idea is

to use a hash. A hash is a fixed value, typically 128 bits, that you derive by means of an algorithm from a variable-length block of text, such as a password. Although a given block of text always generates the same hash value under a given algorithm, it's virtually impossible to obtain the original text that produced a hash value.
Here are some statistical information about the amount of computation you need to break this security system by trying to reverse the RSA algorithm.
If the key is 40 bits wide [available on NT and 98]

Attempts/seconds Average time to break
---------------- -----------------------
1 17432.6425002537 Years
10 1743.26425002537 Years
100 174.326425002537 Years
1000 17.4326425002537 Years
10000 1.74326425002537 Years
100000 0.174326425002537 Years

[hope any one have a multi-processor computer can go this fast]


If the key is 128 bits wide

1 5.39514153540301E+30 Years
10 5.39514153540301E+29 Years
100 5.39514153540301E+28 Years
1000 5.39514153540301E+27 Years
10000 5.39514153540301E+26 Years
100000 5.39514153540301E+25 Years


By storing hash values instead of passwords, you guarantee that even if the password source is compromised, the original passwords won't reveal themselves.
Interesting ha, well, if any one interested more details on this theory and how to use it in the real world you can visit
Once there make sure that you show the toc. You reading
Chapter Twenty Security and Cryptography
Of Windows 98 Developer’s Handbook
After you familiarize your self with this technology, if you need any help in integrating it in VFP you can contact me for sample code.
Hope this will help
Thanks


Walid Magd
Engwam@Hotmail.com
 
shanachie

Just opening the topic a few days back for a question posted by you on 13th Dec'2000 and passing my views (in my last over a decade of using this method, with over 100s of my software installations over 100s of network installations - there is yet one user to break this method and so I am not thinking of revising this method soon), I feel warm and happy to get so many professional views and ideas.. I should congratulate Tek-Tip forum members for making this forum a success and wish for its continued professional growth. Shanachie, you must be happy as well for posting this and getting so many answers :) though late

ramani
 
Hi, don't know whether you have decided on best course of action.

there is a 3rd party add-on that encrypts and entire database and cannot be opened (even by vfp) unless the correct password, and unencryption routine is executed.

The database remains encrypted, even whilst in use by your application.

Check out Xitech cryptor
HTH Have knowledge, lack patience. >:-<
MitchBsc@yahoo.co.uk
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top