devel.cz

Komentáře

• astr258 : Podívej se na to z druhé strany, je-li loginem emailová adresa, pak útočníkovi usnadňujeme práci, protože mu už zbývá jen zjistit heslo. Pokud musí zjišťovat ještě login, má to těžší. — 29.9.2013
• Anonym : astr258: pokud to chci útočníkovi ztížit tak zavést víceúrovňové přihlašování a případnou autorizaci změn prováděných pod uživatelským účtem. Např. je i dobrá možnost nadefinovat IP adresy ze kterých je možné provést přihlášení a pokud se chci přihlásit odjinud tak mít možnost zaslat sms a email s klíči a pomocí jejich kombinace se přihlásit.... Pak mě napadá ještě jedna věc. Jak útočník bude vědět, že zadaný email existuje a slouží jako login? To se nesmí při špatném pokusu o přihlášení napsat "Zadali jste špatné heslo" ale něco ve stylu "Zadané přihlašovací údaje jsou neplatné" - z tohoto nepoznám zda email existuje nebo jsem zadal jen špatné heslo. Dále při opakovaném špatném přihlášení zvětšovat intervaly pro přihlášení a po 5 pokusech zablokovat účet. Při správném přihlášení (pravý uživatel) jej informovat o neoprávněném pokusu se přihlásit a doporučit změnu hesla/ jména. — 29.9.2013
• risa.w : Pokud budete zvětšovat intervaly nebo blokovat účty, tak celý systém nebude zabezpečený proti DoS -- bude celkem snadné konkrétnímu uživateli zabránit v přihlášení. Avšak zpoždění neplatného přihlášení třeba na pět sekund je při hesle délky 5 už dostatečná ochrana proti hrubé síle (cca 520 let a neklesá s počtem strojů). Co se týče jména, přikláním se k názoru, že se jedná o veřejnou část přihlašovacích údajů, a proto se na něj nevztahují bezpečnostní požadavky na utajování -- je tedy irelevantní jestli si ho zvolí sám uživatel nebo mu ho někdo vygeneruje (klidně i veřejně známou metodou) nebo bude stejné jako k jiné službě, bezpečnost to nijak neovlivní, ta stojí a padá na bezpečnosti hesla. A když už někdo najde cestu jak získat heslo, tak už na ní najde i to jméno. — 30.9.2013
• astr258 : V.P.: Existující email v DB může útočník zjistit tak, že si nechá znovuposlat aktivační kód (mám v aplikaci pomůcku Did not receive activation email? Resend it here) nebo resetovat heslo (Forgot your password? Reset it here). Ačkoli i v tomto případě můžu nechat lstivě vypisovat "úspěšnou hlášku", že email s instrukcemi byl odeslán, přestože žádný email odeslán nebyl, jelikož email v DB neexistuje. Nevím pak, zda to nebude matoucí pro uživatele, pokud se uklepne při psaní emailové adresy a bude čekat na příchozí email, který nikdy nepřijde. Nadefinování IP adres: Jak řešit situace, kdy se zákazník potřebuje přihlásit z jiného PC a telefonuje na podporu, abychom mu dočasně přihlašování přes povolené IP zrušili? Jak ho na telefonu autentizovat? — 30.9.2013
• astr258 : risa.w: Ad: zpoždění neplatného přihlášení třeba na pět sekund - ihned, nebo až např. po 10. neúspěšném pokusu o přihlášení? Je dobré dát uživateli možnost, aby si v administraci tuto periodu podle svého nastavil nebo vypnul? A co se týče utajování loginu - mBank mi poslala dopis, ve kterém byl login a heslo pod utajovacím proužkem, který bylo třeba setřít, takže některé banky loginy utajují. — 30.9.2013
• jlkcz : Ačkoliv je to na flame, jakým způsobem se zvyší bezpečnost hesla jeho pravidelnou obměnou? (Popravdě nijak, pravděpodobně uživatel skončí s tím, že bude mít papírky) — 30.9.2013
• risa.w : astr258: "Existující email v DB může útočník zjistit tak, že si nechá znovuposlat aktivační kód" -- Neměl by mít možnost ho zjistit. Krom toho, znalost emailu nesnižuje bezpečnost, útočník nemá do schránky přístup. "ihned, nebo až např. po 10. neúspěšném pokusu o přihlášení" -- to je fuk, 0-10 nehraje žádnou roli. "Je dobré dát uživateli možnost, aby si v administraci tuto periodu podle svého nastavil nebo vypnul?" -- Nemyslím si. Vypnutí snižuje bezpečnost, zvýšení není potřebné a tvorba formuláře je zbytečná investice. jlkcz: bezpečnost hesla nijak, ale zabezpečení vstupu do systému se tím ovlivnit dá (pokud nevíte, že vám uniklo heslo, tak po pravidelné obměně už to nevadí). — 1.10.2013