Securing files by passwords...How secure?

sram

[H]ard|Gawd
Joined
Jul 30, 2007
Messages
1,699
I have been wandering about this for some days now. How hard is it to crack a winrar file and a word file protected by a password? To make it more clear, let's say I have a word file that I protected by a strong password of at least 15 characters and is a mix of small letters/capital letters/symbols and numbers, and -- in addition to that-- I compressed the word file in a rar archive and also protected it with a different but similar strong password.

Can the word file be cracked into? Guessing the two passwords is next to impossible of course, and a dictionary attack will not work. Brute force attack will take ages( Even if it doesn't, we can always increase the number of characters), so is it still doable? Is there a way to get into the program or reverse engineer it or something like that and read the password from within it? Or is Brute force the only way to go? Which is of course fine because the info will most likely lose its value after some time.


Thanks.
 
In my very lmited self study on cryptography, it's apparently possible that double-encrypting an object can actually make it more vulnerable to attack than just single encryption.
 
If they can copy the file, they have as much time as they want. If you are concerned, take the file oof the system and put it on media/drive in a physical safe.
 
In my very lmited self study on cryptography, it's apparently possible that double-encrypting an object can actually make it more vulnerable to attack than just single encryption.

Huh? That doesn't make sense to me! Or do you mean it will attract more people and make them it is something of high value?
 
Huh? That doesn't make sense to me! Or do you mean it will attract more people and make them it is something of high value?

Something to do with creating detectable patterns that could reveal the underlying data. I don't know, it was over my head quite a bit, and may not even be applicable to today's encryption algorithms.
 
If they can copy the file, they have as much time as they want. If you are concerned, take the file oof the system and put it on media/drive in a physical safe.

I don't have anything, I'm just wandering about it. Is it easily breakable or not?

I want to know if they were able to get the file and do all they can do with it, will they find the real data? And what does this have to do with encryption exactly? It is not really encryption, it is more like protection......right?
 
I want to know if they were able to get the file and do all they can do with it, will they find the real data?

The answer to this question, with absolutely every form of encryption technology currently available today (aside from a properly implemented one-time pad) is yes. Given enough time they WILL eventually gain access to the data.

And what does this have to do with encryption exactly? It is not really encryption, it is more like protection......right?

Newer versions of Office (2007 and up I think) use AES-128 to encrypt a document. http://office.microsoft.com/en-us/w...-workbooks-and-presentations-HA010148333.aspx
 
WinRAR/WinZip encryption used to be pathetically weak and vulnerable way back when. There are dozens of password cracking software for those two specifically, but things have changed. They're mostly snake oil programs for brute force attacks now since they've improved drastically over the past decade.

So long as you take the proper steps to securing the file (random characters and long password over 8 characters) it isn't crackable.

A 15 character password in general is not going to be crackable by any reasonable means. Of course despite the bad history that WinRAR/WinZip had regarding passwording files and encryption, you may just want to move to something a little less attractive and with a proven history of being secure.

AxCrypt would get my vote. Doesn't encrypt folders which is a huge negative and kind of makes you scratch your head, but it does do files incredibly well including secure deletion of the original once encrypted.
 
High enough entropy will make it reasonably safe. For example.

26 lower-case alphas
26 capital alphas
10 digits
(We won't even take symbols into account here)

62 possible characters for each position in your password. At 10 characters, you're at 62^10 possible passwords, or 8.4x10^17.

The amount of time it would take to brute force this is immense. Now if you throw in symbols and make it even longer (not that it's necessary), it's not reasonable to crack it.

Moral of the story, use strong passwords and you're relatively safe :)
 
Well, one thing I want to know is that if I use a tremendously strong password(Say 20 characters password while using capital letters, lower-case letters, digits, and symbols), will it be breakable in a reasonable amount of time? Brute force will always work, but here I'm talking about :

26+26+10+20 (assuming symbols are 20) = 82^20 possibilities which will take God knows how long! Brute force will not help here. Is there any other way?
I mean, the password is known to the program/file, right? There might be a way to extract it from the file itself or no?
 
Well, one thing I want to know is that if I use a tremendously strong password(Say 20 characters password while using capital letters, lower-case letters, digits, and symbols), will it be breakable in a reasonable amount of time? Brute force will always work, but here I'm talking about :

26+26+10+20 (assuming symbols are 20) = 82^20 possibilities which will take God knows how long! Brute force will not help here. Is there any other way?
I mean, the password is known to the program/file, right? There might be a way to extract it from the file itself or no?

No the password is NOT known to the program. It uses the password the user put sin to try and decrypt the file, and if it gets back something it understands (archive header, files records, whatever) then it was successful, if not, then the decryption failed. It is possible that someone could find a flaw in the IMPLEMENTATION of the encryption algolrithm and exploit it to get at your data. But assuming a perfect implementation, then no. Brute forcing is the only way to get in without social engineering.
 
Well, one thing I want to know is that if I use a tremendously strong password(Say 20 characters password while using capital letters, lower-case letters, digits, and symbols), will it be breakable in a reasonable amount of time? Brute force will always work, but here I'm talking about :

26+26+10+20 (assuming symbols are 20) = 82^20 possibilities which will take God knows how long! Brute force will not help here. Is there any other way?
I mean, the password is known to the program/file, right? There might be a way to extract it from the file itself or no?



Bruce Force is all about time and pretty much going past 20 characters (given they're all numbers) most people wouldn't even bother with it, even the government unless you're on the Most Wanted list or something where that information can be extremely valuable. I mean just all lower case would be 2 with 28 zeros following.

As someone said below you, programs (the proper ones employing encryption) do not store the passwords or encrypted text in any way, shape, or form. That would be horrifically deceptive encryption and they'd be laughed there way out the market. The only thing a program should remember is the encryption or hashing algorithm employed so it can know what types of hash/encryption process it can process. That's the secret ingredient that makes it all possible.

The only thing you have to worry about is where to store the text file or key, preferably not on the same drive employing the encryption process to. There is one problem that I would always turn off when using encryption of any sorts and that is the sleep states/hybrid mode in Windows. That has been well documented in having the ability to pull keys out of that file because the encryption/decryption process is all done in memory. That memory does not always get dumped, in fact whatever is in the memory when a sleep state/hybrid state is enacted gets saved into a physical file on the drive. If you ask me disable sleep/hybrid mode completely and delete the file if it isn't deleted by default. Do a zero out of the free space on the drive then employee the encryption process with complete confidence.
 
The way I see it is any situation where someone can take an encrypted file to their own network, consider it cracked. it might take 10 years, but eventually, they'll get it if they really want to. They arn't limited by the network, or brute force protective systems, like trying to login to a network service, so they can brute force at pretty much the fastest speed possible, and said speed will increase as more processing power is added. That's for brute force, there may be other ways to do it even faster.

Organizations like the NSA can probably crack such a file in a matter of minutes using methods more advanced than brute force. There's always the possibility that some people may be in on how they do it.

I'd say 90%+ a file encrypted like this is probably safe though. Most people wont bother going far. But the stuff you REALLY need to hide, is the stuff where people/government WILL perhaps go far. (ex: pirated content).
 
Unless you're worried about people with multi-million dollar clusters wanting to crack your files (in which case I'm not sure I want to be helping :D), it's not reasonable that ANYBODY will brute force a reasonably secure password EVER.

Assume thse guys try to crack your password (in which case you have terrible luck). There's not many people with access to systems capable of these kind of numbers. Going back to my example of 8.4x10^17 possibilities for a password of 10 characters, it would take approximately 28 days. Okay, that's kind of scary, but consider the following. Simply upping the password to 15 characters, you've extended the cracking time to approximately 70,063,123 YEARS.

Verdict, use long passwords with a good mix of upper and lower case letters, numbers and symbols. Try to avoid using words that would be found in the dictionary. If it's seriously sensitive data, don't store it anywhere with direct network access.
 
Assume thse guys try to crack your password (in which case you have terrible luck). There's not many people with access to systems capable of these kind of numbers. Going back to my example of 8.4x10^17 possibilities for a password of 10 characters, it would take approximately 28 days. Okay, that's kind of scary, but consider the following. Simply upping the password to 15 characters, you've extended the cracking time to approximately 70,063,123 YEARS.

Woah wonder how they managed to get that many vid cards to work together in a single rig? :eek: Screw cracking passwords, let's mine some bitcoins! :D
 
Hmmm. Interesting! So passwords aren't actually stored. That's nice. You guys have some nice info. I appreciate all your input.

From all what you said, I would say it is impossible to crack a password if:

1- Very Very strong password that is only present in one's brain is used. Don't save it, and don't share it. Well, it is not very difficult to memorize only one password, even if it is long.

2- The program should have some kind of trials/attempts limit, I mean it will just lock out after ten failed attempts.


Is my conclusion correct?
 
Hmmm. Interesting! So passwords aren't actually stored. That's nice. You guys have some nice info. I appreciate all your input.

From all what you said, I would say it is impossible to crack a password if:

1- Very Very strong password that is only present in one's brain is used. Don't save it, and don't share it. Well, it is not very difficult to memorize only one password, even if it is long.

2- The program should have some kind of trials/attempts limit, I mean it will just lock out after ten failed attempts.


Is my conclusion correct?



Is my conclusion correct? 100% correct? or maybe 90% correct?
 
Incorrect. One thing to know is that if you make a password easy to memorize, it will be easier to crack. Any type of common password generation scheme such as keyboard walk patterns are also known by hackers. The hacking programs that brute force don't start at AAAAAAAAAAAAAAAA then increment. They start with the most common password and then do variations, substitutions, and permutations to cut down on probable answers. Using randomly generated passwords help, but then you have to worry about where to store the complex password. Security is only as strong as the weakest link, you need to store the key in an equally secure location.

The second part to limiting access cannot be done if they have a copy of the file. There's no way for a file to enforce attempts on itself, since a copy of the file can be made before attempts are made. The limitations work when a system is granting access, such as windows active directory or google mail. You don't have direct access to the encrypted data.

Also double encryption is more secure than single encryption. The issue is that the level of security only doubles which isn't useful in the world of security. This is why you hear of 3DES( way more than triple secure than DES), although I think AES is more secure.


First thing to understand is that no security system is 100% secure, it's just a question of how long it will take to crack. It all depends on the sensitivity of what you need to protect. 30 days? 1 year? As technology gets faster too, the same levels of security get weaker, so a sufficient system today may not be secure tomorrow.
 
Incorrect. One thing to know is that if you make a password easy to memorize, it will be easier to crack. Any type of common password generation scheme such as keyboard walk patterns are also known by hackers. The hacking programs that brute force don't start at AAAAAAAAAAAAAAAA then increment. They start with the most common password and then do variations, substitutions, and permutations to cut down on probable answers. Using randomly generated passwords help, but then you have to worry about where to store the complex password. Security is only as strong as the weakest link, you need to store the key in an equally secure location.

The second part to limiting access cannot be done if they have a copy of the file. There's no way for a file to enforce attempts on itself, since a copy of the file can be made before attempts are made. The limitations work when a system is granting access, such as windows active directory or google mail. You don't have direct access to the encrypted data.

Also double encryption is more secure than single encryption. The issue is that the level of security only doubles which isn't useful in the world of security. This is why you hear of 3DES( way more than triple secure than DES), although I think AES is more secure.


First thing to understand is that no security system is 100% secure, it's just a question of how long it will take to crack. It all depends on the sensitivity of what you need to protect. 30 days? 1 year? As technology gets faster too, the same levels of security get weaker, so a sufficient system today may not be secure tomorrow.

Fair enough. But I was actually talking about memorizing a complex password that is NOT easy to memorize. But, you are right. I see what you are saying.
 
In my very lmited self study on cryptography, it's apparently possible that double-encrypting an object can actually make it more vulnerable to attack than just single encryption.

In my also very limited self study of cryptography, I'm pretty sure it's the exact opposite, atleast in the context of strong encryptions. The term "round" comes to mind. Serpent (considered stronger than AES, but also slower) for example is 32 rounds, which as far as I know means it goes through it's encryption function 32 times.
 
In my also very limited self study of cryptography, I'm pretty sure it's the exact opposite, atleast in the context of strong encryptions. The term "round" comes to mind. Serpent (considered stronger than AES, but also slower) for example is 32 rounds, which as far as I know means it goes through it's encryption function 32 times.

In my very lmited self study on cryptography, it's apparently possible that double-encrypting an object can actually make it more vulnerable to attack than just single encryption.

I'll explain this a bit more in depth since I'm at a computer for this post.

It doesnt make it less secure, it just isnt as strong as you think it would be.

According to wikipedia, DES use 56 bits for the key. This means that there are 2^56 key combinations for a single pass through. At first thought, if you double encrypt DES with a second key you effectively made the possible of key combinations 2^112 (which is 2^56 squared or 2^56^2), since the space is the cross product of two key ranges.

The reality is that the strength is only doubled(as opposed to squared), the brute force attack only needs to do twice as much searches (ie 2^57 key searches) to break a double DES encrypted piece of information.


This goes off the assumption that the attacker has access to a set of plain text, and its encrypted version. There are many ways for an attacker to get both, but the important part is that if the attacker gets the key, the attacker can now decrypt everything encrypted by that key (or system using that key).

So why is it only double? Simple. Take the unencrypted information, go through all the k1 values, encrypt it, then store the possible values. Take the encrypted information, go through all the k2 values, decrypt it, and find the one that matches with the stored values. Of course this requires storage space, but if we talk about just encryption time, it only takes twice as long as a single DES encryption to break.

To my knowledge, triple DES doesnt allow that to happen, so the complexity goes up to 2^168. But with any type of symmetric encryption (same key to encrypt as decrypt), the same issue applies to double encryption.


TLDR: a double encryption is only marginally stronger than a single encryption of the same type. The strength is actually so insignificantly stronger that double encryption can still considered the same complexity as single encryption.
 
Incorrect. One thing to know is that if you make a password easy to memorize, it will be easier to crack. Any type of common password generation scheme such as keyboard walk patterns are also known by hackers. The hacking programs that brute force don't start at AAAAAAAAAAAAAAAA then increment. They start with the most common password and then do variations, substitutions, and permutations to cut down on probable answers.

Exactly. Here's a good link to read, How crackers ransack passwords like “qeadzcwrsfxv1331”
 
protected by a strong password of at least 15 characters
Thanks.

This has been discussed numerous times on this board.

Basically, a pw of 12+ characters cannot be brute forced in a short while, meaning within
your life time. Winrar uses now 128-bit AES, so yes it's secure; more so than Winzip's 256-bit.

http://hardforum.com/showthread.php?t=1600468&highlight=

http://hardforum.com/showthread.php?t=1610102&highlight=

http://hardforum.com/showthread.php?t=1727196&highlight=

http://hardforum.com/showthread.php?t=1728303&highlight=

http://hardforum.com/showthread.php?t=1764009&highlight=
 
62 possible characters for each position in your password. At 10 characters, you're at 62^10 possible passwords, or 8.4x10^17.

In 2008, IBM's Roadrunner made history (and grabbed the top slot) for cracking 1 petaflop, aka performing 1,000 trillion operations per second [source: IBM].
And Sequoia is 16 times as fast! 16.3 petaflops of performance.

However, no one really knows what the NSA has, thus assume 2x of above speeds.

Symbol count Entropy per symbol
Case sensitive alphanumeric (a-z, A-Z, 0–9) 62 6 bits
All ASCII printable characters 95 6.57 bits

assuming 1,000,000,000,000pws/sec
1 year - 31,500,000,000,000,000,000pws
10,000yrs - 315,000,000,000,000,000,000,000
1m yrs - 31,500,000,000,000,000,000,000,000

62^15 = 781,514,782,079,074,318,856,775,914 total combinations; 25,200,000 years

95^12 = 546,108,599,233,516,079,517,120 - 17,400years

thus, proving length beats symbols.
 
Last edited:
To put it in perspective though these records are increasing by an order of magnitude every 4 years or so
In 1996 a Tera flop was achieved
In 2008 a Petaflop was achieved (4 orders of magnitude)
In 2012 there are contenders in the 16-17 peat flop(another order of magnitude)

I'm not saying this trend will continue forever, but its important to realize with increasingly faster technology, safe (and practical) password techniques don't stay safe forever.
 
In my also very limited self study of cryptography, I'm pretty sure it's the exact opposite, atleast in the context of strong encryptions. The term "round" comes to mind. Serpent (considered stronger than AES, but also slower) for example is 32 rounds, which as far as I know means it goes through it's encryption function 32 times.

Rounds in a cipher is related to the ciphers key schedule. AES128, for example, has 10 rounds and each has a different round key that is derived from the input key material.

Sometimes you will see a program apply the cipher in its entirety multiple times. This is distinct from the concept of a round though and its purpose is to force an attacker to use more resources per an attempt. KeePass, for example, will default to applying AES a multiple number of times so that a decrypt uses a full second of CPU time for the host machine that created the password database.
 
going slightly off-topic, you mentioned specifically about 'password protecting' office documents. as with most things, the devil is in the detail - and specifically here the implementation. it's important to remember that all forms of protection are not necessarily created equal. for example - protecting a worksheet with encryption using a password as the key is one thing, and so long as the encryption algorithm has been implemented properly and you select a good quality key you should be reasonably safe. however, also within office documents - specifically excel - it is possible to use a password to just protect a worksheet for unauthorised modification. this doesn't use encryption, and therefore is not equal, but it does hash the password value and store it within the file. this provides something of a flaw within the implementation of the protection mechanism in that it's possible to extract the hash value from the file and then simply enter the hash value instead of the password to gain access to modify the worksheet. so, in short, never 'assume' that a protection mechanism (even if it uses encryption) is robust! :)
 
Just and FYI; You do not need to crack a password to get in to a WinRAR file or a word document if one exists.

Plus you can use rainbow tables and a good GPU to crack pretty much any password in a very short period of time. If you know how at least.

Give the file to only the people who need it, put a password larger then 39 characters if you can.

I am sure someone will swoop in and try to stone me now that I spoke! :D
 
Just and FYI; You do not need to crack a password to get in to a WinRAR file

Oh really?!
Would you like to elaborate? Provide details and links or info?
Does Winrar have a backdoor the NSA could exploit? A secret backdoor key given to the NSA by Winrar which opens any file?
Again, source?
 
Just and FYI; You do not need to crack a password to get in to a WinRAR file or a word document if one exists.

Plus you can use rainbow tables and a good GPU to crack pretty much any password in a very short period of time. If you know how at least.

Give the file to only the people who need it, put a password larger then 39 characters if you can.

I am sure someone will swoop in and try to stone me now that I spoke! :D

Rainbow tables are not magic bullets. In particular, newer versions of the RAR format use iterations of PBKDF2 with a 64-bit random salt to generate the key from the password. So rainbow tables are no help here.
 
Last edited:
Back
Top