Парола; Weblabor
Търсене
Парола
От следните два низа:
а.) "TQmfz: aVLzMJ6. * б.)" Не може да е толкова много сърца да проливат кръв напразно! "
коя е по-добрата парола? Защо?
Искате ли да поговорим за това? Обсебване
Искате ли да поговорим за това? Или наистина не знаете?
Както и да е, вторият не е толкова печеливш поради акцентите, така че първият в това отношение.
Ако погледнете колко време е необходимо за дешифриране на едното или другото с помощта на груба сила, тогава второто.
Проблемът започва с факта, че за първите така наречени квантови компютри се казва, че са бавни за извършване на подобни атаки (при условие, че имате хеширан файл с парола).
Извинете, много е сутрин.:)
zmt, Yuvat, Sniu "1tg4t.
Как ви харесва това? Можете дори да го отбележите, ако наистина искам:)
Акцент
Бях научен на това,
Проблемът е не
Проблемът не е в това, че не е решен, а в това, че можете да се изправите пред машина, където например няма акцент. Тогава как се влиза? Поради това те обикновено не се препоръчват за идентификатори или пароли. В днешно време трябва да имате достатъчно основи, за да стартирате UTF-8 и т.н. без никакви проблеми.
Можете да кажете, че отсега нататък всички UTF-8 или каквото и да е, просто трябва да обърнете внимание на резервацията, като 1 символ не е сигурен, че може да се побере в 1 байт и т.н. Така че, ако например някой иска да се регистрира в кодирана в унгарски БД с китайски символи, ще има проблеми. В случая на Oracle можете да посочите например дали размерът на текстовото поле е в байтове или символи.
Както и да е, обикновено се препоръчват наистина дълги, лесни за запомняне пароли. За разлика от всички видове крикет-crack пароли.
Не знам колко в наши дни
Клавиатура
Не аз в момента. Но има
Днес: защо не?
Това не се брои за съхранение,
Разбира се, не с парола. С парола има значение само това, което броите от нея. Можете обаче да разчитате на документ за самоличност.
Ако е и аспект,
Как се оказва, че са
речник
Не познавам големия хакер или тъмната страна.:-Д
Прочетох - и не мисля, че е невъзможно - че ако много хешове на пароли попаднат в неоторизирани ръце (напр. Парчето е изхвърлено по някакъв начин), тогава има и някакво решение за речник, но не са написани конкретни данни Предполагам не случайно) и всъщност не ме занимава толкова много.
Ако добре си спомням, смисълът на нещо е, че докато се произвежда пробен хеш с размер на лют червен пипер, всички резултати се запазват (ако има такива) и въз основа на това системата за отгатване е допълнително оправдана. Но не помня конкретната математика, но вероятно дори не е написана.
Все още съм от другата страна, така че по-скоро бих се опитал да се развивам, за да използвам решения, които не са лесни за правене с едно (или хиляди) хешове, независимо каква е паролата зад него. (Очевидно не можете да бъдете напълно независими, но разбирайте добре.)
Може да не си заслужава, но спя спокойно на този сайт.:-Д
Атаката на речника е за.
Атаката на речника е за. това означава (освен ако не помня лошо), че сте дали огромен набор от данни, който съдържа известни пароли и свързаните с тях хешове. Ако имате криптирана база данни с пароли и имате такъв списък (можете да търсите как точно се нарича дъгова таблица), можете да потърсите разширения хеш в тази таблица и вече знаете на коя парола принадлежи.
По принцип това е донякъде защитено срещу така нареченото осоляване, когато към произволната парола се добави някакъв случаен низ, дори нещо различно на парола, преди да се съхрани. Тази "сол" обикновено се съхранява в четлива форма до хеша на паролата (вж. Напр. Параметри на функцията на криптата),.
Или, доколкото знам, за тази цел също се използват множество хешове (т.е. когато изпращате вече завършен хеш във функцията на кодера).
По този начин системата е донякъде защитена от неоторизиран достъп до пароли без груба сила.
Не знам, че би било частичен резултат, напр. груба сила, докато се опитвам, но може да знам грешно.
Широко казано. Разбира се, защитата не вреди, ако потребителят е блокиран за известно време или за постоянно след x опити, така че да не можете да влезете чрез отгатване.
Не разбирам съвсем това
Откъде е това Кой направи това?
Добре, да предположим, че приемаме, че няма нито осоляване, нито n> 1-кратно хеширане, тогава дори аз го генерирах. Но това все още изглежда твърде просто, плюс това беше лошо, ако беше изпълнено едно от горните две условия.
И на практика е по-често yahoo да каже това преди няколко години, че стига до потребителската таблица по някакъв начин и след това се опитва да започне нещо с нея.
- Осоляване: Бих казал днес, че трябва да се използва повече сол. Има нещо, което НЕ е NULL, чието име на колона не е непременно "сол", а (да речем) потребителско име, псевдоним и т.н., а реални данни (за предпочитане повече). Плюс това определено има поне 1 фиксирана сол, която не е в db, а някъде в изходния код/конфигурация и е известна само на този, който има достъп до файловете.