Как да измислите силна парола
Любопитен начин за генериране на силна парола беше предложен от един ентусиаст. Нещо повече, той дори изчисли колко години ще са необходими, за да се разбие такава парола чрез груба сила - 412 трилиона години.
Първо методът, след това обясненията:
Но какво се случва? Първо, данните се вземат от файла /dev/urandom. Ако някой не знае, този файл е интерфейс към ядрото за получаване на псевдослучайни числа. След това, използвайки командата tr, всички знаци, които не могат да бъдат отпечатани на екрана, се изхвърлят. Тогава командата head отпечатва първите 16 знака от потока, а командата echo ги отпечатва.
За по-лесно използване отворете файла
/.bashrc и добавете само един ред:
Вече можете да използвате командата securepw в терминала винаги, когато трябва да зададете силна парола.
Да, и ще получите парола, която не е нещо, което трябва да запомните, но също така е невъзможно да се произнесе. Ако изобщо го разберете. Hike този хакер реши да огъне всички - програмата му дава фиксирана парола:
bash: !@#$%qwertQWERTasdfgASDFGzxcvbZXCVB": събитие не е намерено
Всичко работи. Ето как трябва да бъде (не двойни, а единични кавички):
Всичко става по-лесно
Винаги използвам пароли с дълги фрази, например: ghtlgjxbnf.-ckj;yst-ahfpjdst-gfhjkb (сила 288 бита) или генератор на пароли: g)i(
q=Fwgrm39-Q>!>`s]YmKLF (175 битова сигурност) последният е по-труден за запомняне
Как изчислихте ударите тук, ако не е тайна?
Мога да позная: KeePassX показва криптографска сила - качество на паролата в битове Доколкото разбирам 1 символ = 5 бита
Сякаш броят на битовете също зависи от това кои знаци.
Например една главна или малка буква (в парола,където всички те са един и същ регистър) ще носи log(2,26) -- някъде между 4 и 5 бита информация. Една буква (всеки регистър) или цифра -- log(2,62) -- почти 6 бита. Ако добавите повече символи или използвате български букви заедно с английски, тогава криптографската сила ще се увеличи още повече.
Като цяло, лично мен ме притеснява, че трябва постоянно да измисляте по-дълги и по-дълги пароли и дори 8 букви от различни регистри / номера вече се считат за ненадеждни. (проклетия закон на Мур.)
Ако гражданин използва думи от речник, тогава "битовете" трябва да се броят много по-малко.
Например три думи ≈ (1/100000)^3, някакви жалки милиони милиарди опции (т.е. „50 бита“, някъде). Напълно възможно е да се подреди. Въпреки че тези три думи имат 18 букви, поне 25.
Четири думи от речника ≈ 67 бита, а не 288 бита.Но ако думите в контролния речник са сортирани в низходящ ред по честота и има често срещани думи в паролата, тогава няма да бъде 1/100000 на дума, а например 1/4000, т.е. общо ≈ 48 бита. Така че в "prefer-complex-phrase-passwords" думата "complex" не добавя много към самата сложност ((-;
За тези, които желаят да обсъдят мениджърите на пароли, предлагам да го отнеса в отделна тема, но да не наводнявам тук.
Сложността може да се добави изкуствено, например, като се използва фраза с умишлено AshYPkami или фонетична транскрипция на думи от друга езикова група, например, както през Втората световна война янките са използвали диалекти на индианците (кечуа, гуарани, гуаджиро, аймара) за шифрограми. Можете също да използвате комбинация от различни езици: Rtn-yfabu-gkbp-[tqr[' (4 езика 176 бита) или друг. но безопасно като това: 3.14c.y-Nh`[cjnitcnbltcznbvbkbvtnhjdsq (320 бита)
И още по-лесно, поставяме apg и генерираме пароли, които са в съответствие с FIPS-181 и повече. :)
като опция датаmd5sum глава -c$; ехо;
Можете да събирате не само бази данни с пароли от всички видове поща и VKontakte, но и подобни методи за генериране на пароли.
Вярно, все още не съм разгледал как работи Linux urandom.
Тогава ще цитирам човек 4 произволно
Специалните символни файлове /dev/random и /dev/urandom (достъпни от Linux 1.3.30) осигуряват интерфейс към генератора на произволни числа, вграден в ядрото. Файлът /dev/random има номер на основно устройство 1 и второстепенно устройство номер 8. Файлът /dev/urandom има основно устройство номер 1 и второстепенно устройство номер 9.
Генераторът на произволни числа събира околния шум от драйвери на устройства и други източници в ентропиен пул. Генераторът също постоянно оценява броя на битовете шум в ентропийния пул. Именно с помощта на този пул се създават случайни числа.
При четене устройството /dev/random връща единични произволни байтове, броят битове шум в които е равен на броя битове шум в ентропийния пул. /dev/random трябва да се използва, когато се изисква висок коефициент на произволност , като например когато се използва еднократно криптиране (еднократна подложка) или когато се генерира ключ. Ако ентропийният пул е празен, опитът за четене на /dev/random ще доведе до забавяне, докато не се събере повече околен шум.
Когато се чете, /dev/urandom ще върне толкова байта, колкото са поискани . В резултат на това, ако няма достатъчно ентропия в пула, тогава върнатите стойности са теоретично слаби срещу криптографска атака върху алгоритмите, използвани от драйвера. Как да направите това не е в днешната некласифицирана литература, но теоретично е възможно такава атака да съществува. Ако е важно за вашето приложение, използвайте го по-добре/dev/random.
Надявам се, че в Linux този проблем не е толкова пренебрегван (1950-60-те отдавна са отминали :-)
Изглежда, че това са само най-общите съображения, а останалото е по преценка на разработчиците. Тоест, необходимо е да се разгледат алгоритмите в изходните кодове на конкретни реализации на ядрото.
FreeBSD и OpenBSD вече са го направили, точно както писах по-горе.
Изглежда, че вместо термина "сол", от криптографската литература, Unix използват термина "ентропиен басейн".
вместо термина "сол", от криптографската литература, Unix използва термина "ентропиен пул"