Hide table in vfp

[jhonny03]

Is there a possible way to hide tables after program is installed in drive C?
my reason is for the password of users are seen there if thy are opened..
or is it encryption is the best way?

 

[Scott24x7]

Encryption is really the best way. You can "hide" the file with attribute +h of a file, but that won't hide it's contents.
You can use a field level algorithm to encrypt them. A reversible algorithm will allow you to compare them at entry time.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Tore Bleken]

Never store passwords in a table, or anywhere else. In other words, don't store them at all. Instead you create what's called a hash of the password, and store that in a table. If a user forgets his password, then he must be given a new one by the administrator.

http://www.foxpert.com/docs/security.en.htm

 

[GriffMG]

tbleken is correct, never store a raw password in the context of any kind of user name - unless you aren't really concerned
about security.

Use a hash to create a NON reversible code. But don't just use the password the user entered to create it
you need to 'salt' the password with something else to make it secure. This is a minimum

m.SecretSaltString = "TekTipsWasFoundToBeVeryGood, EspeciallyIn 2015..." && your very long Salt key, could be a novel 128 bytes would be enough

m.UserID = "Fred Bloggs"  && as entered by the user when setting up password

M.Password = "MyWeakPassword"  && as entered by user when setting up password

m.MyHash = HashAlgorithmOfYourhoice(HashAlgorithmOfYourhoice(m.SecretSaltString+m.UserID+HashAlgorithmOfYourhoice(m.Password)))

Using the UserID as part of the salting process ensures every salt is different, but repeatable by you (the time of day would be
no good - as you would not know the original one to do a comparison later).

Most people seem to use many multiples of the HashAlgorithmOfYourhoice() parts - some doing it hundreds of times - to try and
make it harder, I am not sure how much difference that makes, the key is to choose a hash algorithm you are happy with, you could
look at MD5 as a starter, there a few hashes to choose from.

Keep your salt as secret as possible - don't store it in plain text for post it on FB, encapsulate your encryption code and don't
leave that lying around.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Mike Lewis]

For a simpler way of encrypting the password, consider using SYS(2007). You don't need a seed, and you can do the whole thing in a single function call.

But the principle is the same. Never store unencrypted passwords. And do the encryption locally, so the unencrypted version is never sent over the network.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

While SYS(2007) is a useful hash, without the seed (or salt) a rainbow table will reveal the original password in a blink.

People have invested a lot of work in creating rainbow tables to enable original passwords to be worked out - and published them
on the web - along with tools that enable you to enter the encrypted password and get one or more cyphers (wrong word I know,
but I am not a crypto expert) back that would work.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

Well, very good, but partl wrong. Indeed you can leave your code and salt lying around quite open. It's even good to store the salt string used in the record.
The highered security of a salted hash is, that you use a different salt per hashing and that there is no so called rainbow table to get bak to the password.

I'd have to write a lot to explain, in short the hashing is a irreversable thing in itself, so you later can't decode the password from the hash, but you instead hash the reentered password and see if the hash is the same as stored. The good thing is, that not only you and your code cann't decode the password from the hash, but aso a hacker or a user finding your dbf can't. But using just MD5 you can google the hexstring and most probably find a password that becomes that value, when MD5 is applied to it. That reverse lookup is possible, as there are tables of millions of passwords and their MD5 value, for example. So while the hash function doesn't allow a reverse computation the known hashes can be retranslated and if users use weak passwords it's likely you find the hash and corresponding clear text password.

Useing salt means you hash more than the password, that generates hashes, which most probably are not found in such rainbow tables. Though the can contain millions of hashes and ther corresponding password, adding a random dalt value means much more and differing hash values, that can't possibly be stored in a rainbow table in all billion trillion gazillion brazillian combinations.

In more detail look at OWASP:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

One detail at

https://www.owasp.org/index.php/Pas...ographically_strong_credential-specific_salt:

Generate a unique salt upon creation of each stored credential (not just per user or system wide)

Don't use CRC32 or MD5, the value range of these hash functions is too small. Use something like SHA-256, SHA-512 or HMAC-SHA-256. Craig boyd has written vfpencryption.fll, that includes such hash functions, unfortunately his blog is down. If you look for encryption in vfp solutions.app you'll find sample useing the windows crypto API.

Bye, Olaf.

 

[GriffMG]

This is a good link:

https://www.bentasker.co.uk/blog/security/201-why-you-should-be-asking-how-your-passwords-are-stored

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

Yes, that's really a good reading.

Bye, Olaf.

 

[Mike Lewis]

I suggested using SYS(2007) (or, to be more precise, using a CRC checksum) simply for the sake of simplicity. I'm not claiming it will provide the highest possible level of security, but that's wasn't the original question.

I suspect that in the situation faced by the original questioner, a simple checksum would be more than adequate. If higher security is required, then perhaps he shouldn't be using VFP tables to store his data.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Indeed a secure login on an othe3rwise unencrypted VFP database is like a secure lock on a paper door. That's of course something to consider, too.

Bye, Olaf.

 

[GriffMG]

Not quite, with one you are protecting your data, with the other you are protecting their
login and user name - which might be considered a responsibility...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[jhonny03]

tnx guys for the advice..i chose to use the SYS(2007) and my question is
how to decrypt the password after being encrypted..

 

[GriffMG]

Hi
JHonny03

The point is that you cannot 'decrpyt' the password after hashing it.

You have to take the password as entered on a future date and encrypt that
then compare the two encrypted versions.

You have to reset the password to a known value if you need to help the
user out later.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[GriffMG]

Did you salt or seed your Sys(2007)?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[jhonny03]

i thought sys(2007) can be decrypted..
what is the simplest and easiest way to encrypt password from the table..

 

[Tore Bleken]

Look here for code to generate hash values:

http://fox.wikis.com/wc.dll?Wiki~VfpMd5HashFunction

 

[Olaf Doschke]

with one you are protecting your data, with the other you are protecting their login and user name

Well, if you can get at the unencrypted data without using the app and its login at all, the protection is pointless as said: as a secure lock on a paper door.
The least thing to do is put the data on a share only accessible to users also having a login, but you can't limit the access to the logged in state only, therefore the door to the files is always open.

Bye, Olaf.

 

[GriffMG]

If all you have done is something like this:

replace userstable.password with sys(2007,userstable.password)

There is no easy way to recover what password was.

You can compare a users 'logging in' password to it easy enough

if userstable.password == sys(2007,thisform.password.value)
  ** ok go ahead
else
  ** no don't go ahead
endif

If you want to make it a bit more secure you could reprocess you usertable thus:

replace all usertable.password with sys(2007,"my enormous secret salt string..."+usertable.password)

Then you would need to do this to verify it (roughly)

if userstable.password == sys(2007,"my enormous secret salt string..."+sys(2007,thisform.password.value))
  ** ok go ahead
else
  ** no don't go ahead
endif

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[GriffMG]

I agree, Olaf, but I was trying to differentiate between your applications data and
your responsibility to at least try and keep passwords confidential on the assumption
that someone somewhere may one day do a talk-talk on you. They aren't going to be taken to
the cleaners for what they had in the way of their own data - but they might be for not
securing the passwords and other details of their users. I suspect their data was inside
secure(ish) SQL servers and they have faired no better than if they had stored it in
an open share and VFP tables.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​