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 TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Password Problem 2

Status
Not open for further replies.

FoxKid

MIS
Jun 8, 2003
92
IN
Hi All,
I have made a passward program in which I get username & password from the user. Then I tally it to the password I have saved in one dbf. But the problem is that anybody can access that dbf and locate password from there. This is unsecure. I want to save in such a place where I myself should not know, what is the password. Is it possible as it has been done in windows password.

Thanks and regards
 
You can develop an algorithm to encrypt the password and store the only encrypted password in the password table. Additionally you can rename the password file with a non dbf extension like aaa.txt to make it more difficult for someone to find out the file containing the use-id/password.

 
You might want to check the examples in this thread:
thread184-318598
 
FoxKid,

The way I handle this is not to store the password anywhere. Instead, I calculate the checksum of the password and store that. When the user enters the password, I calculate the checksum again, and compare it against the stored value.

That way, you have no risk of someone deriving the password from the stored value; the password is never transmitted over a network; and you don't have to worry about writing an encryption routine.

To calculate a checksum, use SYS(2007).

Mike



Mike Lewis
Edinburgh, Scotland
 
Mike,
While I've used a variant of your technique, the big problem with SYS(2007), is that it's only got 65,535 possible results. Depending on your requirements for the format of your password, you can get unintentional "duplicates". Of course, you can prevent those by adding some user specific info or by using another checksum or hashing routine that provides more possibilities. Of course resticting the number of "bad" entries is also a good idea to prevent a calculated attack.

Rick
 
Rick,

That's a good point. On the other hand, what is the problem with having duplicates? Remember, we are not interested in deriving the password from the checksum .. only the reverse.

I suppose it's possible for someone to try entering random passwords, and for one of them to be accepted, even though it is not the correct one. I'd guess there'd be a one-in-65,535 chance of that.

You could always store two checksums (with different seeds) for any one password. That would reduce the odds to one in 65,535 ^ 2.

Mike


Mike Lewis
Edinburgh, Scotland
 
I work on an application that operates over a network.

I use API calls GetUserName & GetComputerName which operate on the name used to log in and the computers name to make sure I know who's using the system and what rights they should have.

Stewart
 
I do store the passwords and usernames in a table. I use the encryption/decryption routines as outlined by the example in the solution.app that comes with VFP.

DO (Home()+"samples\solution\solution.app")

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]
 
HI
Have a look in
How to build a Password control for you application?
faq184-1262

As pointed out, the limitation of 65535 is there.

There is another way to increase the complications by simply doing...
passwordStored = ALLT(checksum)+ALLT(checksumof a derivedPass)
where derived pass can be another word generated by str convertions of the password.
:)



ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 
FOXKID,

Try this. Just cutandpaste into a prg and run with the necessary parameter.

Code:
PARAMETERS cPass2chk

*!*	This routine assumes that your password input textbox returns Character Data
LOCAL nLenfPass AS String
LOCAL cEncrypt as String
LOCAL nChopping as Integer
LOCAL cControlBit as string
LOCAL cRetValue as String
LOCAL cThisSum as String

IF TYPE('cPass2chk')<>&quot;C&quot; then
	RETURN REPLICATE(&quot;*&quot;,10)
ENDIF

*!*	I am going to concatenate the checksum value of each character of the password with a control bit

cRetValue		=	&quot;&quot;
cPass2chk		=	ALLTRIM(cPass2chk)
nLenfPass 		= 	LEN(cPass2chk)


	FOR nChopping 	= 	1 TO nLenfPass
		cControlBit	=	ALLTRIM(STR(nChopping))
		cThisSum	=	LEFT(SYS(2007,SUBSTR(cPass2chk,nChopping,1)),3)		&& First three Character of the Checksum of each character
		cRetValue	=	cRetValue + cControlBit + cThisSum
	NEXT chopping

RETURN cRetValue
 
Thankyou everybody....
I will try all and revert soon.

Thanks and Regards
 
Ramani,

where derived pass can be another word generated by str convertions of the password

Or, take the checksum again, but using a different seed.

By the way, I hadn't realised you wrote a FAQ on this point, otherwise I would have credited you with it.

Mike


Mike Lewis
Edinburgh, Scotland
 
Nice Sys(2007) function - never noticed it before - was saving encryted password in a table.

Any ideas how to reverse the process (use the checksum to determine password) e.g user forgets password?

I guess this would be hard as you mentioned there could be duplicates - different cExpressions result in same checksum.

mrF
 
MrF,

Any ideas how to reverse the process (use the checksum to determine password) e.g user forgets password?

No. The whole point is that you cannot reverse it. If you could, the password would not be secure.

Although every string has a unique checksum, it is not true that every checksum has a corresponding unique string.

Mike


Mike Lewis
Edinburgh, Scotland
 
Theoretically i can check all strings (composed of permissible letters and signs) -> ;)

Monika from Warszawa (Poland)
(monikai@yahoo.com)
 
Hi MikeLewis,

Although every string has a unique checksum, it is not true that every checksum has a corresponding unique string.

I think you did not mean that verbatim.
Every string has a checksum.. but need not be unique.


And now to every one... regarding passwords... some more ideas..

1. Login names to be enforced as atleast of 5 characters.
2. Convert the the first 5 characters to a key board difficult string.. example..
****************
cString = INPUTBOX(&quot;Key in your password&quot;)
cString=ALLTRIM(cString)
n = LEN(cString)
cNewStr = ''
FOR I = 1 TO n
cNewStr = cNewStr+CHR(ASC(SUBSTR(cString,i,1))+123)
ENDFOR

WAIT WINDOW cNewStr
****************
(I have just shown a way. It is assumed, no ones name can consist of characters beyond CHR(122) and so.. adding 123 to the ASC value will not exceed the limit of 255.)

2. Now think in the same way converting entire passwords also into a string. Now make the password as this string+the checksum as in the FAQ. This will eliminate some one trying to key in numbers one by one and breaking it.

3. When the use keys in the password.. the same string convertion can be done and added with SYS(2007) will give a nice combination.

:)

Also, this leaves room for the originator of the code to know the password by working backword.(A word out from the developer can make the Easter Egg surprises and break-ins.. The downside !)

ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 
Hi Ramani 1
i used similar idea in my application some years ago, but now i have it in my home PC
regards

Monika from Warszawa (Poland)
(monikai@yahoo.com)
 
Monikai,

Theoretically i can check all strings (composed of permissible letters and signs) -> ;)

Yes, OK. I agree (reluctantly). But that still doesn't answer Mr F's point. Theoretically, any number of strings can generate the same checksum. If you tried every permissible combination, you still wouldn't know which of the possible strings was the original password.

Ramani,

I think you did not mean that verbatim.
Every string has a checksum.. but need not be unique.


Well, a given string will always generate the same checksum, assuming you are using same algorithm and the same seed. But a given checksum won't necessarily &quot;generate&quot; the same string. (Yes, I know, a checksum can't generate as string, but you know what I mean).

Mike





Mike Lewis
Edinburgh, Scotland
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top