Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Say that my password is PASSWORD1 I have a 10MB jumbled text file. I hide my password in two parts in the text, between > and < so I can find it myself. Then I put the 2 parts together and add the 1 by keyboard. How easy is it for security experts to find it?

Ä)e÷>WORD<Æ­iW+¯S¥\«…%‹&Ìâœê–f0ãídá¾Ûùvÿ²
åŒëР8ïÙtFJÍÕ9"Å¡”HŸuîP‚†ÃLjaãæôZÚ4ÊGhsg&87&
ᮊmŲ„Ç“wcD~MÚ««B­qeBY>PASS<ÒJÕþ3c§Jhew

So I can retrieve the two parts, know which order to put them and add the 1, PASSWORD1. How safe is hiding a 30 character length password in a 10MB file. Can anybody ever figure it out? Can it be brute force cracked?

I add an example, I give no hints, what is the password?

rV\}c¸š;íâN_qy£ÆŠû]c½ìkŒCKg{ÅS¬#ˆ!“Iè§éÛJÏówgÓˆ†ü¤ªÔ#
¡<çX=áVøì4}©,5ÇÜëŸMž" ìɺQZl’~?ùÓ“lÙ+³zyä¸Ê¯Z×LË­UÃì²Rÿ•
Ï.väÐõG6¼S'ÿ{JZ/ûrŒÇ,æÁ|ŠhþqQ×^Á¼rIn€ýtUµûH›ï•³Õ{YJÒØPÕ{
7ušÆ“ð"$‡ÆnZhµ©TÿL@MÖ¤)¯"Œ×¹ &Ыˆ.ÛÖõsªsoäÜh9É"1Mw˜ÚV
xÁeÇr‘"¯J§’+§I¿câ§n(ú¥!Ɖã•gr`rÅE[•7Z^<„íl÷æ¶"¬s®ûBõ*|
E{3áÛØÓU—%ÀÂùÉhs5IDWá@ûÀSGâœ9u-Êwª(BÜÅ3mâ̛YÑ á~N‘~¥¼ªž(
DÀ¯¿æ'ãV˜F¦ÝjBî\{`nÂFhUêÖc›B¿Æ¿O òl*£HÒmQ&#÷‰1¸?ŸÇ ¯óà
1ur4sÚø±–îuÛ´n*Oã](¿™e/ì)b¤ëZòW%Ë@uf„á1xã?VTe*ã»]µªëÑ&d
<Kk³-õ®+П5ÃmaŸ2s\Ö©þAxllÖÚõj[kñ;6ÊT‚ΔnŒ!e }è[ê•ŒÒSÖ
yÓ'Ë0îè/õTjfØ,úÍ„•u?NTÅG'Ðt!Xp‚¸ú“9áAÝ»»Ø{ ›Ç¬T[ѺmM¡ƒ²ÿV
ÈÉsÅLÀ©ä¢I_’©>ÔÒT·žÇüyúÀBå½Õ¾÷é'Í¥’¡|¼ªú%²9° ŒU¿Uzè¯ÑÔÕ
¶œUÉÅësl]úÃl^ßNž÷éwÙì('ä‡/!yGF4‘”â“Z†^MfÿhYç&çhåxŠ}€X
´ˆøHYKå:żf,Ò¤%uí;óÌ?®ÁùE%ÄãDp.Edñ†ÂXÙiÚŒÒ)ГKƒp;ﲋ6f
qiª{@3;ïØýnN¶î¼SkÒŸ‡‹£92’K•˜ûÚ‹$ü²t³â‡zðŠ‰ev[Òòìϼºˆ
gT÷Ÿè»A*É무C£VšØ·¹'vRôûì7ZgÀ`{){Þ‡mËŽ¨Ä!*|ÔŒSlÅ´'áãÀì.
ã’S·ÔüE»q4Ô#ÜòëÛFhì˜9À\­àÄhé¡êhr.‡AJ;a3ørJJPÀ]½Ø²ýäUXnu

I'm not trying to be smart, I just want to understand how a specialist would go about finding it. Thank you all for your time!

I guess nobody can give me the rough numbers.

share|improve this question
5  
I know this doesn't really answer the nature of what you're asking, but grep -P -o '>.*?<' –  Jeff Ferland Mar 21 '13 at 17:05
5  
Short answer is, very easy. So don't do it. –  Adnan Mar 21 '13 at 17:21
    
You know there are password safes like keepass which store your passwords in a truly safe manner (assuming the one master password that you still have to remember is not too easy to guess)? –  Tobias Kienzler Mar 22 '13 at 9:50

7 Answers 7

A cryptanalyst would probably just do this by hand;

  • This is a text file.
  • All printable characters.
  • Frequency analysis shows 2 * '<' and 2 * '>' which is true of all plaintexts, whereas all other character frequencies change, which probably means something interesting is going on.

I would say less than an hour to figure out your password scheme. Significantly faster if we have multiple text files.

share|improve this answer
    
thank you for your answer. obviously I would not use the > < characters as my personal markers, but in this exact example I would use say a "p" something that will be abundant in the huge text file. –  Peter Mar 21 '13 at 17:09
    
If you are using something abundant, how are you personally going to extract your password? –  lynks Mar 21 '13 at 17:11
    
by adding a small piece from memory to the 2 compiled parts I would make it impossible to find the password from the textfile? yes? –  Peter Mar 21 '13 at 17:14
3  
@Peter your method is only secure if your passwords are statistically identical to the background 'noise'. –  lynks Mar 21 '13 at 17:22
6  
Why not just use an encrypted file, or one of the many dozens of capable password managers that exist? You appear to be solving a problem, poorly, that has already been solved relatively well. –  Stephen Touset Mar 21 '13 at 20:35

The weakness you've got relates to frequency analysis. You have 10,485,760 bytes, and since this looks like 8 bit glyphs, you'd expect them to average 40,960 instances of any given character.

Given 10mb and that delimiter, here's my frequency analysis:

    (000): 41332
    (001): 41363
    (002): 41272
    (003): 41180
    (004): 41416
    (005): 41357
    (006): 41263
    (007): 41224
    (008): 41233
    (009): 41427
    (010): 41538
    (011): 41179
    (012): 40937
(013): 41020
    (014): 41294
    (015): 41406
    (016): 41410
    (017): 41312
    (018): 40820
    (019): 41534
    (020): 40948
    (021): 41375
    (022): 41410
    (023): 41616
    (024): 41239
    (025): 40966
    (026): 41097
    (027): 41114
    (028): 41554
    (029): 41097
    (030): 41037
    (031): 41123
    (032): 41139
!   (033): 41184
"   (034): 41348
#   (035): 41328
$   (036): 41330
%   (037): 41653
&   (038): 41415
'   (039): 41253
(   (040): 41223
)   (041): 41119
*   (042): 41355
+   (043): 41439
,   (044): 41047
-   (045): 41169
.   (046): 41441
/   (047): 40835
0   (048): 41377
1   (049): 41607
2   (050): 41185
3   (051): 41044
4   (052): 41223
5   (053): 41399
6   (054): 41020
7   (055): 41276
8   (056): 41278
9   (057): 41072
:   (058): 40885
;   (059): 41354
<   (060): 2
=   (061): 41513
>   (062): 2
?   (063): 41168
@   (064): 41226
A   (065): 41236
B   (066): 40838
C   (067): 41400
D   (068): 41560
E   (069): 41387
F   (070): 41329
G   (071): 41131
H   (072): 41295
I   (073): 41371
J   (074): 41565
K   (075): 41204
L   (076): 41512
M   (077): 41517
N   (078): 41819
O   (079): 41302
P   (080): 41128
Q   (081): 41258
R   (082): 41166
S   (083): 41002
T   (084): 41166
U   (085): 40740
V   (086): 41226
W   (087): 41483
X   (088): 41554
Y   (089): 41376
Z   (090): 41283
[   (091): 41404
\   (092): 41154
]   (093): 41547
^   (094): 41092
_   (095): 41145
`   (096): 41284
a   (097): 41440
b   (098): 41397
c   (099): 41729
d   (100): 41207
e   (101): 41492
f   (102): 40711
g   (103): 40949
h   (104): 41336
i   (105): 41464
j   (106): 41441
k   (107): 41375
l   (108): 41017
m   (109): 41080
n   (110): 41041
o   (111): 41113
p   (112): 41347
q   (113): 41003
r   (114): 41083
s   (115): 41719
t   (116): 41459
u   (117): 41338
v   (118): 41014
w   (119): 41035
x   (120): 41566
y   (121): 41246
z   (122): 41426
{   (123): 41132
|   (124): 41368
}   (125): 41431
~   (126): 41177
    (127): 41429
Ä   (128): 41449
Å   (129): 41384
Ç   (130): 41041
É   (131): 41363
Ñ   (132): 41438
Ö   (133): 41263
Ü   (134): 41240
á   (135): 40954
à   (136): 41169
â   (137): 41143
ä   (138): 41461
ã   (139): 41320
å   (140): 41336
ç   (141): 41353
é   (142): 41319
è   (143): 41419
ê   (144): 41430
ë   (145): 41632
í   (146): 41265
ì   (147): 41613
î   (148): 41197
ï   (149): 41418
ñ   (150): 41477
ó   (151): 41341
ò   (152): 40975
ô   (153): 40873
ö   (154): 41295
õ   (155): 41432
ú   (156): 41112
ù   (157): 41749
û   (158): 40802
ü   (159): 41439
†   (160): 41297
°   (161): 41003
¢   (162): 41062
£   (163): 41188
§   (164): 41579
•   (165): 41333
¶   (166): 41430
ß   (167): 41130
®   (168): 41405
©   (169): 40966
™   (170): 41260
´   (171): 41392
¨   (172): 41353
≠   (173): 41433
Æ   (174): 41548
Ø   (175): 41541
∞   (176): 40993
±   (177): 41166
≤   (178): 41786
≥   (179): 41179
¥   (180): 41178
µ   (181): 41251
∂   (182): 41261
∑   (183): 40697
∏   (184): 41346
π   (185): 41587
∫   (186): 41109
ª   (187): 41323
º   (188): 41517
Ω   (189): 41382
æ   (190): 41203
ø   (191): 41117
¿   (192): 41184
¡   (193): 41223
¬   (194): 41115
√   (195): 41029
ƒ   (196): 41640
≈   (197): 41496
∆   (198): 41551
«   (199): 41577
»   (200): 41391
…   (201): 41080
    (202): 40931
À   (203): 41386
à  (204): 40966
Õ   (205): 41638
Π  (206): 41309
œ   (207): 41443
–   (208): 41417
—   (209): 41309
“   (210): 41242
”   (211): 41030
‘   (212): 41526
’   (213): 41225
÷   (214): 41410
◊   (215): 41262
ÿ   (216): 41181
Ÿ   (217): 41443
⁄   (218): 41013
€   (219): 41743
‹   (220): 41436
›   (221): 40906
fi   (222): 40784
fl   (223): 41082
‡   (224): 41470
·   (225): 41368
‚   (226): 41204
„   (227): 41648
‰   (228): 41050
   (229): 41504
Ê   (230): 41010
Á   (231): 41477
Ë   (232): 41477
È   (233): 41510
Í   (234): 41383
Î   (235): 41544
Ï   (236): 41505
Ì   (237): 41451
Ó   (238): 41159
Ô   (239): 41469
   (240): 41191
Ò   (241): 41305
Ú   (242): 41349
Û   (243): 40778
Ù   (244): 41280
ı   (245): 41400
ˆ   (246): 41496
˜   (247): 41219
¯   (248): 41188
˘   (249): 40921
˙   (250): 41230
˚   (251): 41245
¸   (252): 41175
˝   (253): 41288
˛   (254): 41495
ˇ   (255): 41249
share|improve this answer
    
Jeff thank you for your answer. I don't understand what your calculation means. I'll have to study some on the subject. My delimiter would in real life not be as clear cut as my example showed. If you would look at my second example maybe it would not be so clear cut? –  Peter Mar 21 '13 at 18:06
    
@Peter it's a demonstration that if you scroll through my list, you should visually see the flaw. –  Jeff Ferland Mar 21 '13 at 18:22
    
I did see that my specifically chosen delimiters had a 2, but what if my first delimiter would have been the first occurrence of (031) until I reach a (210) and my second part between the last (071) and say... (251) then my data disappears in the numbers right? –  Peter Mar 21 '13 at 18:38
    
@Peter No. The point is that it is only possible to have one (or a few at most) of each of your delimiters because there must be nothing between them other than your password. The larger the file, the most the delimiters will stand out in a frequency analysis. (You could put pairs of delimiters together with nothing in between them until you have 40,000 delimiters but then frequency analysis of pairs of characters looks obvious.) –  Ladadadada Mar 21 '13 at 18:54
    
please look in my second example above. for my first half of the password I picked start after the first copyright sign, until you reach the space - so - ,5ÇÜëŸMž" my second half starts at the fourth to last line after ed - till you get to the ) so - ñ†ÂXÙiÚŒÒ add test123 from memory and voila - my password: ,5ÇÜëŸMž"ñ†ÂXÙiÚŒÒtest123 - but.... how could you have possibly known this? –  Peter Mar 21 '13 at 19:15

between > and < so I can find it myself

Well, that's it. Whatever your "hiding method", you have to remember a way to find it back. So you password is not the sequence of characters which you ultimately type on the keyboard; your real password, the "secret convention" that you keep in your brain, is the method: find the two strings enclosed in '>' and '<', concatenate them, and append a '1'. What the attacker needs to do is to find that method.

How secret can such a method be ? Well, not much. First, you just published it on the Internet. Second, you will apply it regularly, and your open-the-file-search-for-'>' will be quite visible for shoulder surfers. In particular, the elements of your password will appear in plain view. Finally, your hiding method introduces biases: in a 10 MB file full of random bytes, you should have about 40 thousand times each byte value on average (since there are 256 possible byte values); but, for your method to be unambiguous, you need to remove all '>' from the file, except the two you will keep to mark the two halves of your password (otherwise, you will not be able to find the right elements of your password). An attacker will simply count the number of times each byte value appears in the file (the pompous name for that is frequency analysis); he'll find that each byte value appears about 40000 times (as expected), except '>' and '<' which appear only twice each. He'll have no trouble figuring out that these two byte values are "special" and are associated with your password hiding place...

Not knowing how much secret the password is, is already a big issue; most of security analysis is about quantifying things. But, in your case, we can qualitatively state that your password will not be much secret at all.

share|improve this answer
    
Thank you so much for your clear explanation. In my second example above I don't give clues. I have in my mind the two sets of delimiters, I can find them without fail. The character distribution in a 10MB file will be somewhat evenly. So if all characters from the 256 set are evenly distributed, will it be "easy" to find my 2 password parts? How much number crunching will it require to try all possibilities? And... after I have compiled my password, I'll add some characters from memory. –  Peter Mar 21 '13 at 18:57

Simply don't try something like this. It is reinventing the wheel and making it a triangle. First, it is easy for someone to figure out the scheme and break it, second, even if they are really lazy, there are a very limited number of possibilities throughout the file that could be tried randomly when compared to the entropy in even a fairly short password. You are much better off to use a cryptographic key store like Keepass where the passwords are encrypted with one master password which you simply memorize.

share|improve this answer
    
I use last password, but that's not what I'm after. I am just curious how experts would go about starting to attack the problem. In my example 2 you don't have the delimiters, you don't have the length of the parts, you don't know the part I would add. So how many possibilities are there? –  Peter Mar 21 '13 at 18:09
    
In a 10mb file there are only about 50 trillion possible phrases. Assuming that we start with the shorter length though and work our way up, it is significantly fewer possibilities. Lets say we limit each section to 20 characters, there are then only 200 million or so options. That's only 40 quadrillion pairs. That's only the same entropy as a 9 digit alpha-numeric password, and that assumes that the distribution within the file is purely random, which would make recovery of the information difficult. Since something needs to key the information, it would likely be far easier than brute. –  AJ Henderson Mar 21 '13 at 18:19
    
Also, keep in mind, it was an effective reduction from 40 digits of alpha-numeric/symbol entropy down to only 9 digits of alpha-numeric entropy, which is itself a HUGE loss of security, even for brute force. –  AJ Henderson Mar 21 '13 at 18:21
    
thank you so much for your time. I just don't understand enough about what you are saying. I need to start studying on the concepts mentioned. I just thought that making it hard and the possibilities numerous AND adding some part from memory, it would be impossible to find. 10MB file and two 50 random character parts any better? –  Peter Mar 21 '13 at 18:45
    
@Peter - when evaluating the strength of a cryptosystem, you are trying to measure entropy, or randomness. Assuming the best case (there are no patterns and everything is truly random) then you can look at what the maximum number of tries would be to get a baseline. Since we have two parts and don't know how many characters out of the 10mb file may be part of it. We have 10 million single character parts, 9,999,999 2 character parts, etc up to however many characters we think there could be in the part. We then have two of those so we square that number. That gives us the total number of –  AJ Henderson Mar 21 '13 at 18:56

Brute force attacks don't work like that, I assume you meant dictionary attack where a wordlist of probable passwords is supplied and brute forcer tool/software (i.e john the riper) rotates one by one until it finds right one. In a jumbled text, I don't know any way for a password cracking tool to find alphabets because there will be so much jumbled text it may not be able to read it. However, normally there are text parser which parse text for you or extract binary file data to text. Answer to your query is YES.

Alternative A secure alternative I suggest is always storing your sensitive information using strong encryption algorithms such as SHA-256/or higher.

share|improve this answer
    
by brute force I meant, try all possible character combinations in the text file at all possible lengths in all different orders. –  Peter Mar 21 '13 at 17:07
    
oh and thank you for your answer as well :-) The mentioned password that I'm hiding is for an encrypted container, but I wanted an easy place to hide it. because I add two parts from the text file (from the 256 character set) and add a piece of my own I thought I could be secure. –  Peter Mar 21 '13 at 17:12

I'm going to give this scheme maximum benefit of the doubt. Here's my take on it, with conclusion at the bottom:

We've got a file with 10,000,000 7-bit characters, chosen truly randomly. This means every character should appear, on average, every 128 characters. I'm going to refer to this size as a block below.

I'm also going to assume that you're going to specify a key along the lines of "start at the Yth '>' after the 'Q' after the start of the Nth block and finish at the tenth character", because that would be easy to remember. This means that your password is actually randomly determined, and initially unknown to you. A ten-character password chosen at random like this is actually fairly strong. That's 70 bits of randomness.

The first issue is that for each block of 128 characters, there's roughly a 36% chance that any given character doesn't appear in that block. This multiplies as you add on additional blocks, so there's a roughly 13% chance that a 'Q' doesn't appear in two blocks in a row, and a 0.003% chance that a 'Q' won't appear in 10 blocks in a row. That means that only 1 in 27351 sets of 10 blocks will be missing a 'Q'. However, we have a lot of data! We've got 78125 blocks in this file, so we would expect, on average, to find three such 10-block regions without a 'Q' in our 10 MB file. Things get weird when you're dealing with large numbers.

This means we may have to search quite a ways to find the first Q after the start of the Nth block. There's a low chance of it, but as we've seen, there are likely to be three places in our giant file where we have to search roughly a KB of text (manually!) for a single 'Q'. When you consider that we want not just the first but the Nth '>' after that Q, things quickly get complicated. We might have to search through 1 KB for the Q, and then another 1 KB to find the first '>'.

All this means in practice is that we know your password won't be in the last 150 KB or so of the file, because you can't guarantee that any particular pair of characters will be in there in the order and number required.

It also means that we can calculate a key size. You need five pieces of information to find your password in the file: the starting block, the first character, the number of second characters to count ahead, the second character, and the stop character.

We can specify this as a series of numbers and characters: [ 7685, 'Q', 6, '>' ], which means "Start reading at the 6th '>' after the 'Q' in the 7685th block.

Since there are roughly 78000 blocks you can choose for the starting point, that value has between 16 and 17 bits of randomness. It could be any number between 0 and 78000. For characters, you've got 128 choices in two positions, which is 7 bits of randomness each, or 14 bits total. The second number is tricky. Since we can reasonably expect to count ahead at least 1 KB to find each character, it's probably safe to choose a value less than 64 here. That's only six bits of randomness. So, grand total, your key has ( 16-ish + 14 + 6 ) bits of randomness, which is 36-ish bits. If you vary the length, you could add a few more bits. While not trivial, a typical modern home computer could power through all possible combinations in a couple days.

However, as others have pointed out, this is all largely irrelevant. The file itself only has 10,000,000 possible starting points. That means that the key space is actually significantly smaller than the keys themselves, and you really only have around 23 bits of randomness. What this means in practical terms is that each starting position in the file can be referenced by 16,000 different keys, and, actually, memorizing a starting position is significantly easier than memorizing that key structure. If you use a smaller block, there are even fewer possible combinations.

Conclusion: So yeah, as others have said, this is a bad idea. Use a known strong encryption program using a known strong password. You can come up with a password that's easier to memorize that gives you considerably more protection than this convoluted scheme, and you get the benefit of tried and tested encryption algorithms.

share|improve this answer
    
Thank you for your answer. I'll have to sit down and let it all sink in. –  Peter Mar 22 '13 at 21:43
    
I realized on the way home from work that my keying idea is actually quite poor, since all you'd need is the second character '>' to dramatically reduce the search space. There are probably only around 78000 of whatever the second character is in the file, and your password must be after one of them. There are more complicated ways of expanding the key in a more secure fashion, but the point is that it doesn't matter how much you expand the key - there are only 10,000,000 possible "addresses" for the key to reference in the first place. –  Devin R Mar 22 '13 at 21:55
    
Another way to look at it: Your password has to start after 1 of 128 possible characters - that's 7 bits of randomness. There are probably 78000 or so of those in the file - that's another 16 bits of randomness. Add those together (so you start at the Xth Y) and you get 23 bits, which is, not coincidentally, the same amount of randomness as brute-force searching the whole file. Any scheme on top of this just duplicates keys. –  Devin R Mar 22 '13 at 22:02

Please don't try to create your own encryption scheme. Some of the most researched algorithms have failed. Your encryption method will fail to a frequency analysis. Based on what you said: you split your password into two parts. Your encrypted cipher would have to be analyzed for any character that occurs four times, and brute force it from there. For example I see that the '¬' character occurs four times. I am sure there are better ways to break it. Even if you split your passwords into more parts, that would only mean increasing the frequency analysis by a bit. I don't understand what you're trying to achieve here.

share|improve this answer
    
Thank you for your response. What I was going for is the pure number crunching needed to find all possibilities in a 10MB text file to find my 76 character split up password. I'll divide it in parts, I'll be flawless in putting them together. My markers will be only known by me. I'm in no way trying to "create my own encryption scheme". All I want is to be able to store a hidden password in a big flat text file, in order to recreate a very long password that unlocks my (conventionally) encrypted data. –  Peter Mar 21 '13 at 20:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.