| Author |
Message |
Guest
|
 Posted: Fri Dec 12, 2008 5:29 pm Post subject: |
 |
|
| TGRMN Software wrote: | The encryption password is stored encrypted in the profile file .fsf. Without the profile file .fsf, encrypted files are safe.
With access to the profile file .fsf a professional could decrypt the password (he/she would need to reverse engineer the ViceVersa code for this) and then he/she could decrypt the files. It would be quite difficult and expensive to do this but possible. Without access to the .fsf file it is not possible. |
Why does a professional need to decrypt the password stored in the fsf file? Anyone with the fsf file can run it and decrypt any files previously encrypted with that profile. There's no request to re-enter your password and check it against a hashed value before you are able to run the profile.
| Quote: | Of course it would still be possible to perform a 'dictionary attack' on the encrypted files where common password are tried on your encrypted files. That is why it is important to choose a complex password, not to be found in a dictionary. This is important for any password  |
How strong does the password need to be? I ask because when people ask about encryption here the answer is often "AES-256". That doesn't mean very much. In practice AES 256 isn't any more secure than AES 128. Adobe Acrobat 9 uses 256 bit AES and SHA-2 hashing which should be very secure but there's no salting or key strengthening so the implementation is vulnerable the use of rainbow tables, brute force and dictionary attacks, much more so than the earlier version that on the face of it used a weaker cipher and a weaker hash function. The result is that passwords that would have been secure in earlier versions aren't anymore and users have to create passwords that are significantly longer. See: blogs.zdnet.com/security/?p=2271
It would be good to have a lot more details. |
|
| Back to top |
|
 |
TGRMN Software
Site Admin
Joined: 10 Jan 2005
Posts: 8763
|
| Posted: Mon Dec 15, 2008 3:34 am Post subject: |
|
|
| Quote: | | Why does a professional need to decrypt the password stored in the fsf file? Anyone with the fsf file can run it and decrypt any files previously encrypted with that profile. There's no request to re-enter your password and check it against a hashed value before you are able to run the profile. |
You are right! ViceVersa can be used to decrypt the files in that case. But without the .fsf file, that is not possible. Note that the .fsf profile file itself could be protected by using the Windows file permissions and encryption system.
| Quote: | How strong does the password need to be? I ask because when people ask about encryption here the answer is often "AES-256". That doesn't mean very much. In practice AES 256 isn't any more secure than AES 128. Adobe Acrobat 9 uses 256 bit AES and SHA-2 hashing which should be very secure but there's no salting or key strengthening so the implementation is vulnerable the use of rainbow tables, brute force and dictionary attacks ...
|
ViceVersa encryption does use hashing, salting and key strengthening, but it is always more secure to use a password that:
- it's long (let's say at least 10 chars)
- it's not found in a dictionary
- contains numbers and letters
- contains non-characters (e.g. _, +, %, ^)
- contains capital letters
thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com |
|
| Back to top |
|
|
Guest
|
| Posted: Tue Dec 16, 2008 5:17 pm Post subject: |
|
|
| Quote: |
ViceVersa encryption does use hashing, salting and key strengthening, but it is always more secure to use a password that:
- it's long (let's say at least 10 chars)
- it's not found in a dictionary
- contains numbers and letters
- contains non-characters (e.g. _, +, %, ^)
- contains capital letters
thanks |
Great. I agree about creating passwords and agree about protecting the fsf file as the fsf file as it exists is essentially a key file. That said I still think you should post a lot more details on your website.
Also, I don't understand the hashing. What's the point? It looks like you enter a password and it is hashed and the hash is stored in the fsf file but you don't have to authenticate in anyway to run the fsf file (i.e. re-enter the password, have it hashed and compared with the stored hash). Maybe in a future version there will be an option to authenticate before the fsf file runs?
How's the salting done? Without the details just saying the hashing is salted doesn't mean much. For example, WPA-PSK authentication on wireless routers uses the SSID for salting but if you use the default SSID (i.e. "linksys" on Linksys routers) or something that's common or predictable, the salting is ineffective.
What's the nature of the key strengthening? How's it done? Roughly how many passwords/sec could be tested using a typical Intel desktop processor, say an Intel 2.3GHz quad core which you can pick up for under $200 retail?
I think VVP is a great program and use it all the time for synchronizing and backing up data but I think you need to do a lot of work to make the security/encryption part convincing. Lots of programs encrypt data, but without the details it just comes over as marketing. |
|
| Back to top |
|
|
TGRMN Software
Site Admin
Joined: 10 Jan 2005
Posts: 8763
|
| Posted: Wed Dec 17, 2008 1:29 am Post subject: |
|
|
Hi
| Quote: | | Also, I don't understand the hashing. What's the point? It looks like you enter a password and it is hashed and the hash is stored in the fsf file but you don't have to authenticate in anyway to run the fsf file (i.e. re-enter the password, have it hashed and compared with the stored hash). Maybe in a future version there will be an option to authenticate before the fsf file runs? |
It is not the password hash that it is entered in the .fsf file, it is just the encrypted password that ViceVersa needs to run without asking the password each time (i.e. in scheduled mode).
| Quote: | | How's the salting done? Without the details just saying the hashing is salted doesn't mean much. For example, WPA-PSK authentication on wireless routers uses the SSID for salting but if you use the default SSID (i.e. "linksys" on Linksys routers) or something that's common or predictable, the salting is ineffective. |
A salt is used to make dictionary attacks more difficult http://en.wikipedia.org/wiki/Salt_(cryptography)
But since an attacker can study the ViceVersa PRO source code, the attacker knows what salt is used (not very easy to do, but possible)
So it is very important to use a complex password to protect files (as it is with any application) in order to avoid that a hacker could just guess your password and decrypt files.
There are a lot of internal, propetary mechanism in ViceVersa PRO, including the format of the encrypted file, which make it difficult to try a dictionary attack.
In future versions we are also planning to add an additional safety mechanism by using the Windows encryption API, i.e. link the password to the master account password too, without storing that info in the fsf file.
thanks
www.tgrmn.com
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com |
|
| Back to top |
|
|
Guest
|
| Posted: Wed Dec 17, 2008 3:22 pm Post subject: |
|
|
I know what a salt is. The question is, do you? It appears from what you have stated that the same salt value based on something in the VVP code is used each time. That's not a salt. A salt is some random value or value with very low predictability, unique to each user or instance, that's attached to a password before it is hashed. That's what makes use of rainbow tables impractical.
Whatever is stored in the fsf file, the actual password, a hash, or an encrypted version of the password is really beside the point. If you have the fsf file you don't need anything else to decrypt the data. The fsf file should be protected as it is equivalent to having the password in clear text.
You didn't answer the other question about time factor involved in an attack.
This exchange could go on and on. The details don't really matter. Unless you state how you have implemented the encryption so we can all understand what's happening, whatever you say isn't going to be very convincing. And I think you should want to go into some detail on these matters because if you have done it properly, then it's a great selling point. And if you haven't, then being open and getting feedback will help you get to where you need to be. There are lots of large companies that have made a real mess of encryption in otherwise excellent products. Good encryption is hard to do properly. Why should I trust you more than them? It's all very well to go on about internal, proprietary mechanisms but I'm going to go with Bruce Schneier on this one: "Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code."
And I'd be carefully about linking your encryption to anything implemented by Microsoft. Windows passwords, particularly those stored using the LM hash, are notoriously easy to crack. |
|
| Back to top |
|
|
TGRMN Software
Site Admin
Joined: 10 Jan 2005
Posts: 8763
|
| Posted: Thu Dec 18, 2008 4:34 am Post subject: |
|
|
Hello,
| Quote: | | I know what a salt is. The question is, do you? It appears from what you have stated that the same salt value based on something in the VVP code is used each time. That's not a salt. |
Password salt used by ViceVersa is different each time and generated randomly at run time (one of the factors used is the current time). The salt, password and intermediate hash values are run through the hash function multiple times. Password hash is then saved.
| Quote: | | Whatever is stored in the fsf file, the actual password, a hash, or an encrypted version of the password is really beside the point. If you have the fsf file you don't need anything else to decrypt the data. The fsf file should be protected as it is equivalent to having the password in clear text. |
Yes, using the profile file (.fsf) data can be decrypted. The profile file (.fsf) needs to be kept separated from the encrypted data. In a future version we will add the option not to store the password in the .fsf file at all. In that case ViceVersa won't be able to run automatically (because password is not stored, and needs to be entered each time). But the advantage is that even with the fsf file the data cannot be decrypted unless the password is known.
| Quote: | | You didn't answer the other question about time factor involved in an attack. |
Attacker would need to hash each password in a dictionary several times and compare it vs. the password hash created by ViceVersa PRO until a match is found.
thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © phpBB Group
|
ViceVersa HOME 
Forum FAQ
Search Forum
Register
Profile
Log in
