Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Stanford univ. wachtwoord regels
Op security.stackexchange.com vond ik een verwijzing naar nieuwe password regels bij IT-services van Stanford University. Wat mij be- en opvalt:
- Een glijdende schaal voor eisen van aanwezigheid van hoofdletters, symbolen, kleine letters, cijfers: boven lengte 12 zijn alleen Hoof-, kleine en cijfers nodig, boven de 19 zijn er geen regels, alles is goed.
- Alles betekent niet echt alles: Stanford checkt elk wachtwoord tegen een blacklist. Letterlijk staat er:
The password-checking system screens all passwords against its own large dictionary of over 63 million English and non-English common words, common passwords, passwords that have been leaked by various compromises, and other passwords that attackers may be able to guess.
-Er is aandacht voor wachtzinnen (pass phrases)
Verfrissend, en helemaal mee eens.
Voor liefhebbers die niet geloven dat bijvoorbeeld uitsluitend kleine letters een sterk wachtwoord kan opleveren, staat op ongeveer 1/3 van de lange webpagina http://en.wikipedia.org/wiki/Password_strength een tabel "Lengths L of truly randomly generated passwords....." met een vergelijking van de sterkte van wachtwoorden en wachtzinnen bij gebruik van verschillende tekensets.
- Een glijdende schaal voor eisen van aanwezigheid van hoofdletters, symbolen, kleine letters, cijfers: boven lengte 12 zijn alleen Hoof-, kleine en cijfers nodig, boven de 19 zijn er geen regels, alles is goed.
- Alles betekent niet echt alles: Stanford checkt elk wachtwoord tegen een blacklist. Letterlijk staat er:
The password-checking system screens all passwords against its own large dictionary of over 63 million English and non-English common words, common passwords, passwords that have been leaked by various compromises, and other passwords that attackers may be able to guess.
-Er is aandacht voor wachtzinnen (pass phrases)
Verfrissend, en helemaal mee eens.
Voor liefhebbers die niet geloven dat bijvoorbeeld uitsluitend kleine letters een sterk wachtwoord kan opleveren, staat op ongeveer 1/3 van de lange webpagina http://en.wikipedia.org/wiki/Password_strength een tabel "Lengths L of truly randomly generated passwords....." met een vergelijking van de sterkte van wachtwoorden en wachtzinnen bij gebruik van verschillende tekensets.
Reacties (28)
Tijd om http://xkcd.com/936/ eens te updaten :)
Zie ook https://www.security.nl/posting/385802/Universiteit+adviseert+wachtwoord+van+meer+dan+20+karakters
20-06-2014, 11:54 door
Dick99999
@11:06 Anoniem
Dank je, had ik helaas gemist.
Maar de kop "Universiteit adviseert wachtwoord van meer dan 20 karakters" zet mensen op het verkeerde been. Stanford adviseert juist een glijdende schaal: 8 tekens mag best, maar dan ook symbolen etc gebruiken, 20+ mag best, maar dan geen regels etc. Her artikel zelf maakt dat onderschijd overigens wel.
De blacklist check komt niet aan de orde daar. En er blijft veel verwarring over de sterkte van wachtzinnen, ook onder het commentaar.
Dank je, had ik helaas gemist.
Maar de kop "Universiteit adviseert wachtwoord van meer dan 20 karakters" zet mensen op het verkeerde been. Stanford adviseert juist een glijdende schaal: 8 tekens mag best, maar dan ook symbolen etc gebruiken, 20+ mag best, maar dan geen regels etc. Her artikel zelf maakt dat onderschijd overigens wel.
De blacklist check komt niet aan de orde daar. En er blijft veel verwarring over de sterkte van wachtzinnen, ook onder het commentaar.
20-06-2014, 12:41 door
PietdeVries
De vraag is waarom je eigenlijk een zo lastig mogelijk te brute-forcen wachtwoord nodig hebt?!?
Als een website na 5 foute inlog pogingen mijn account blokkeert, dan zou zelfs welkom1234 nog goed genoeg zijn (want 1 karakter meer dan het standaard welkom123 - dus dat red je niet in 5 pogingen). Voor website toegang of authenticeren tegen een live systeem heeft een complex of lang wachtwoord dus geen enkele zin. Een lang wachtwoord heeft wel zin om het moment dat een hacker er met de wachtwoorden database vandoor gaat. Dan kan je offline lekker brute-forcen om te achterhalen welk wachtwoord bij welke hash hoort.
Maar goed beschouwd lost dat lange wachtwoord dus alleen maar een probleem van zwakke hashes op. Als het creëren van een wachtwoord hash een seconde of 5 duurt, dan is brute-forcen niet langer mogelijk want veel te langzaam.
Laten we dus zoeken naar complexere hashing algoritmes en niet naar complexere wachtwoorden. De technische oplossing van het algoritme is makkelijker te implementeren dan het veranderen van de menselijke natuur...
Als een website na 5 foute inlog pogingen mijn account blokkeert, dan zou zelfs welkom1234 nog goed genoeg zijn (want 1 karakter meer dan het standaard welkom123 - dus dat red je niet in 5 pogingen). Voor website toegang of authenticeren tegen een live systeem heeft een complex of lang wachtwoord dus geen enkele zin. Een lang wachtwoord heeft wel zin om het moment dat een hacker er met de wachtwoorden database vandoor gaat. Dan kan je offline lekker brute-forcen om te achterhalen welk wachtwoord bij welke hash hoort.
Maar goed beschouwd lost dat lange wachtwoord dus alleen maar een probleem van zwakke hashes op. Als het creëren van een wachtwoord hash een seconde of 5 duurt, dan is brute-forcen niet langer mogelijk want veel te langzaam.
Laten we dus zoeken naar complexere hashing algoritmes en niet naar complexere wachtwoorden. De technische oplossing van het algoritme is makkelijker te implementeren dan het veranderen van de menselijke natuur...
20-06-2014, 12:53 door
User2048
Ik vind het rekenen aan wachtwoordcomplexiteit maar schimmig.
Neem de volgende situaties:
a: Het wachtwoord mag alleen letters bevatten.
b: Het wachtwoord mag letters en speciale tekens bevatten.
c: Het wachtwoord moet letters en speciale tekens bevatten.
Volgens mij levert situatie b de grootste complexiteit op. Immers voor iedere positie in het wachtwoord heb je alle mogelijke letters en speciale tekens ter beschikking. In situatie c moet je na een x aantal letters beslist kiezen uit de kleinere set van speciale tekens. In situatie b zijn "abcdefgh" en "!@#$%^&*" allebei toegestaan, maar in situatie c niet. Situatie b levert meer mogelijke wachtwoorden op dan c.
Toch dwingen we meestal situatie c af.
Statistiek en kansrekening is nooit mijn sterke kant geweest, maar hier heb ik gelijk. Toch?
Neem de volgende situaties:
a: Het wachtwoord mag alleen letters bevatten.
b: Het wachtwoord mag letters en speciale tekens bevatten.
c: Het wachtwoord moet letters en speciale tekens bevatten.
Volgens mij levert situatie b de grootste complexiteit op. Immers voor iedere positie in het wachtwoord heb je alle mogelijke letters en speciale tekens ter beschikking. In situatie c moet je na een x aantal letters beslist kiezen uit de kleinere set van speciale tekens. In situatie b zijn "abcdefgh" en "!@#$%^&*" allebei toegestaan, maar in situatie c niet. Situatie b levert meer mogelijke wachtwoorden op dan c.
Toch dwingen we meestal situatie c af.
Statistiek en kansrekening is nooit mijn sterke kant geweest, maar hier heb ik gelijk. Toch?
Door PietdeVries: De vraag is waarom je eigenlijk een zo lastig mogelijk te brute-forcen wachtwoord nodig hebt?!?
Als een website na 5 foute inlog pogingen mijn account blokkeert, dan zou zelfs welkom1234 nog goed genoeg zijn (want 1 karakter meer dan het standaard welkom123 - dus dat red je niet in 5 pogingen). Voor website toegang of authenticeren tegen een live systeem heeft een complex of lang wachtwoord dus geen enkele zin. Een lang wachtwoord heeft wel zin om het moment dat een hacker er met de wachtwoorden database vandoor gaat. Dan kan je offline lekker brute-forcen om te achterhalen welk wachtwoord bij welke hash hoort.
Maar goed beschouwd lost dat lange wachtwoord dus alleen maar een probleem van zwakke hashes op. Als het creëren van een wachtwoord hash een seconde of 5 duurt, dan is brute-forcen niet langer mogelijk want veel te langzaam.
Laten we dus zoeken naar complexere hashing algoritmes en niet naar complexere wachtwoorden. De technische oplossing van het algoritme is makkelijker te implementeren dan het veranderen van de menselijke natuur...
Je geeft zelf al een deel van het antwoord op je vraag: onderscheid online en offline. Als de website na 3-10 keer blokkeert is een eenvoudig wachtwoord voldoende. Als een website na 5 foute inlog pogingen mijn account blokkeert, dan zou zelfs welkom1234 nog goed genoeg zijn (want 1 karakter meer dan het standaard welkom123 - dus dat red je niet in 5 pogingen). Voor website toegang of authenticeren tegen een live systeem heeft een complex of lang wachtwoord dus geen enkele zin. Een lang wachtwoord heeft wel zin om het moment dat een hacker er met de wachtwoorden database vandoor gaat. Dan kan je offline lekker brute-forcen om te achterhalen welk wachtwoord bij welke hash hoort.
Maar goed beschouwd lost dat lange wachtwoord dus alleen maar een probleem van zwakke hashes op. Als het creëren van een wachtwoord hash een seconde of 5 duurt, dan is brute-forcen niet langer mogelijk want veel te langzaam.
Laten we dus zoeken naar complexere hashing algoritmes en niet naar complexere wachtwoorden. De technische oplossing van het algoritme is makkelijker te implementeren dan het veranderen van de menselijke natuur...
Maar hoeveel sites, routers en andere bestemmingen doen dat vandaag? Zonder blokkade kan een hacker online 1000 tot 10000 keer raden, maar dan nog is een iets sterker wachtwoord voldoende. En dat onbeperkt raden merk je niet op je thuis router.
Ook de offline variant noem je: dan hangt de kraakbaarheid af van het wachtwoord, de capaciteit en van de hash functie. In theorie is het mooi om te " zoeken naar complexere hashing algoritmes" maar als je vandaag bescherming wilt hebben, moet je sterke wachtwoorden nemen om tegen offline kraken bestand te zijn.
Overigens geeft mijn gratis tool SimThrow, een schatting van de sterkte van wachtzinnen, juist rekening houdend met die verschillende scenario's: online/offline, applicatie type (SIP,TrueCrypt, password kluis. Wifi), hash methode etc.
zie: zie http://itura.nl/infosec.html
En de huidige versie heeft een unieke grafiek: de kans dat het het wachtwoord op dag 1 geraden wordt. Dit omdat al de gebruikelijk kansberekening zoals 'het duurt gemiddeld 50 jaar' voorbij gaan aan wat er op de eerste dag geraden wordt.
Door User2048: Ik vind het rekenen aan wachtwoordcomplexiteit maar schimmig.
Neem de volgende situaties:
a: Het wachtwoord mag alleen letters bevatten.
b: Het wachtwoord mag letters en speciale tekens bevatten.
c: Het wachtwoord moet letters en speciale tekens bevatten.
Volgens mij levert situatie b de grootste complexiteit op. Immers voor iedere positie in het wachtwoord heb je alle mogelijke letters en speciale tekens ter beschikking. In situatie c moet je na een x aantal letters beslist kiezen uit de kleinere set van speciale tekens. In situatie b zijn "abcdefgh" en "!@#$%^&*" allebei toegestaan, maar in situatie c niet. Situatie b levert meer mogelijke wachtwoorden op dan c.
Toch dwingen we meestal situatie c af.
Statistiek en kansrekening is nooit mijn sterke kant geweest, maar hier heb ik gelijk. Toch?
Je kan de fout in de redenering gemakkelijk inzien. Welke van de volgende wachtwoorden denk je dat sterker is:Neem de volgende situaties:
a: Het wachtwoord mag alleen letters bevatten.
b: Het wachtwoord mag letters en speciale tekens bevatten.
c: Het wachtwoord moet letters en speciale tekens bevatten.
Volgens mij levert situatie b de grootste complexiteit op. Immers voor iedere positie in het wachtwoord heb je alle mogelijke letters en speciale tekens ter beschikking. In situatie c moet je na een x aantal letters beslist kiezen uit de kleinere set van speciale tekens. In situatie b zijn "abcdefgh" en "!@#$%^&*" allebei toegestaan, maar in situatie c niet. Situatie b levert meer mogelijke wachtwoorden op dan c.
Toch dwingen we meestal situatie c af.
Statistiek en kansrekening is nooit mijn sterke kant geweest, maar hier heb ik gelijk. Toch?
Jn*0a4^12JQ7 (complex voorbeeld)
lr92hp7lybehe2l8ecb1caul90l58tkyfuvzfm173ts883op4cvjieg1pqfziq8ktnbkwx209gw0k66c
Wat je vergeet mee te nemen is de lengte en die wint het van complexiteit bij ongelijke lengte:
Uitgerekend in combinaties: 96^12 (eerste voorbeeld) < 36^80 (2-de voorbeeld) ofwel 6.1E+23 < 3.2E+124 (ja honderd 24) combinaties.
En dat is waarom Stanford een glijdende schaal heeft, boven de 20 tekens heb je geen complexiteit meer nodig en boven de 12 steeds minder complexiteit ( let wel: voor bescherming van je Stanford account/kostbaarheden)
20-06-2014, 14:27 door
User2048
@Dick99999: Het is geen fout in mijn redenering. Ik ga bij mijn redenatie uit van gelijke lengte van het wachtwoord in alle drie gevallen. Dat verschilt van de situatie bij Stanford, waar inderdaad een glijdende schaal wordt gebruikt. Ik bedoel mijn gedachtenexperiment in een meer algemene context.
Als wachtwoorden minimaal 8 karakters moeten zijn, dan zullen de meeste gebruikers precies 8 karakters gebruiken, gemakzuchtig als ze zijn. Als je vervolgens de eis toevoegt dat er letters en speciale karakters in moeten zitten, dan verklein je de toegestane wachtwoordruimte ten opzichte van de situatie waar letters en speciale karakters mogen maar niet moeten.
Ik ben het met je eens dat Stanford een goede benadering kiest.
Als wachtwoorden minimaal 8 karakters moeten zijn, dan zullen de meeste gebruikers precies 8 karakters gebruiken, gemakzuchtig als ze zijn. Als je vervolgens de eis toevoegt dat er letters en speciale karakters in moeten zitten, dan verklein je de toegestane wachtwoordruimte ten opzichte van de situatie waar letters en speciale karakters mogen maar niet moeten.
Ik ben het met je eens dat Stanford een goede benadering kiest.
"Je geeft zelf al een deel van het antwoord op je vraag: onderscheid online en offline. Als de website na 3-10 keer blokkeert is een eenvoudig wachtwoord voldoende. Maar hoeveel sites, routers en andere bestemmingen doen dat vandaag? "
Ze zouden het allemaal moeten doen. Zaken als maximum aantal inlogpogingen instellen e.d. zijn wel iets voor de beheerders van een site; gebruikers gaan daar niet over en hebben daar dus meestal weinig invloed op.
Ze zouden het allemaal moeten doen. Zaken als maximum aantal inlogpogingen instellen e.d. zijn wel iets voor de beheerders van een site; gebruikers gaan daar niet over en hebben daar dus meestal weinig invloed op.
Door PietdeVries: De vraag is waarom je eigenlijk een zo lastig mogelijk te brute-forcen wachtwoord nodig hebt?!?
Precies. Mensen die dit soort verhalen schrijven weten absoluut niet waar ze mee bezig zijn!
Het invoeren van dit soort krankjoreme password regels verbetert de veiligheid niet, maar verslechtert die juist.
Als je het systeem veilig wilt maken dan is het belangrijk dat je je eerst realiseert dat je met wachtwoorden geen
veilig systeem kunt maken. Dat probleem lost je dus op door niet (alleen) met wachtwoorden te werken, niet
door allerlei eisen aan wachtwoorden te stellen.
Bedenk: je wilt bepalen wie iemand IS. Dat kun je niet door te kijken wat die persoon WEET.
Probeer je dat toch, dan heb je al verloren.
@16:06 door Anoniem
In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog. Wat heb je dan aan de constatering dat de site zou moeten weten wie iemand is? Sites, behalve blijkbaar jouw eigen 'systeem', vragen toch een password?
Ik ben ook heel benieuw welke NIET "krankjoreme password regels" de beveiliging wel verbeteren. En waarom de Stanford regels de veiligheid verslechteren.
==== edit 19:00 herformulering
In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog. Wat heb je dan aan de constatering dat de site zou moeten weten wie iemand is? Sites, behalve blijkbaar jouw eigen 'systeem', vragen toch een password?
Ik ben ook heel benieuw welke NIET "krankjoreme password regels" de beveiliging wel verbeteren. En waarom de Stanford regels de veiligheid verslechteren.
==== edit 19:00 herformulering
Door User2048: Ik vind het rekenen aan wachtwoordcomplexiteit maar schimmig.
Neem de volgende situaties:
a: Het wachtwoord mag alleen letters bevatten.
b: Het wachtwoord mag letters en speciale tekens bevatten.
c: Het wachtwoord moet letters en speciale tekens bevatten.
Volgens mij levert situatie b de grootste complexiteit op. Immers voor iedere positie in het wachtwoord heb je alle mogelijke letters en speciale tekens ter beschikking. In situatie c moet je na een x aantal letters beslist kiezen uit de kleinere set van speciale tekens. In situatie b zijn "abcdefgh" en "!@#$%^&*" allebei toegestaan, maar in situatie c niet. Situatie b levert meer mogelijke wachtwoorden op dan c.
Toch dwingen we meestal situatie c af.
Statistiek en kansrekening is nooit mijn sterke kant geweest, maar hier heb ik gelijk. Toch?
Neem de volgende situaties:
a: Het wachtwoord mag alleen letters bevatten.
b: Het wachtwoord mag letters en speciale tekens bevatten.
c: Het wachtwoord moet letters en speciale tekens bevatten.
Volgens mij levert situatie b de grootste complexiteit op. Immers voor iedere positie in het wachtwoord heb je alle mogelijke letters en speciale tekens ter beschikking. In situatie c moet je na een x aantal letters beslist kiezen uit de kleinere set van speciale tekens. In situatie b zijn "abcdefgh" en "!@#$%^&*" allebei toegestaan, maar in situatie c niet. Situatie b levert meer mogelijke wachtwoorden op dan c.
Toch dwingen we meestal situatie c af.
Statistiek en kansrekening is nooit mijn sterke kant geweest, maar hier heb ik gelijk. Toch?
Zoek een 5-VWO'er op die wat handiger is , en laat die wat sommetjes maken.
Het is niet zo moeilijk, om het relatieve verschil in voor een paar interpretaties van b en c uit te rekenen.
(verlies je bij c alleen de optie n-positie wachtwoord van _alleen_ letters [a-zA-Z] ? Of wil je c als meervoud lezen en is de beperking 'n karakters waarvan minimaal twee gekozen uit de set 'speciale tekens' ? )
In theorie heb je gelijk , bij gelijke lengte is je onbeperkte keuze pool wat groter dan een keuze pool met een paar randvoorwaarden.
Gegeven dat gebruikers mensen zijn, kun je dat in je policy maar beter meenemen, en er _niet_ uitgaan dat alle uitkomsten van een 'willekeurige' trekking van een n-letter password even waarschijnlijk zijn.
Oftewel, je brengt een bias aan bij de symbool keuze als tegenwicht op de bias die gebruikers hebben.
(mijn natte vinger zegt dat het relatieve verschil tussen de grootte van de pools erg klein zal zijn. Ik kan 't prima uitrekenen, maar dat ga ik nu niet doen. )
Zoals hierboven aangegeven is een heel sterk wachtwoord alleen nodig indien 'iemand' met de database met wachtwoorden er vandoor gaat. Dus een website blokkeert een account voor een minuut na iedere foute inlog poging, en blokkeert account voor langere tijd na meerdere foute inlog pogingen.
Waarom staan (hashes+salt van) wachtwoorden in een database?
Het is op zich helemaal niet nodig om een wachtwoord in een (enkele) database te hebben staan. Ik daag jullie uit om met een andere oplossing te komen!
Idee soep: browser plugin (ID store) | heel veel mini databases op server | aparte user server | notify/response via mobile app | geen SQL db gebruiken | LDAP etc
Rene
Waarom staan (hashes+salt van) wachtwoorden in een database?
Het is op zich helemaal niet nodig om een wachtwoord in een (enkele) database te hebben staan. Ik daag jullie uit om met een andere oplossing te komen!
Idee soep: browser plugin (ID store) | heel veel mini databases op server | aparte user server | notify/response via mobile app | geen SQL db gebruiken | LDAP etc
Rene
Door Anoniem: "Je geeft zelf al een deel van het antwoord op je vraag: onderscheid online en offline. Als de website na 3-10 keer blokkeert is een eenvoudig wachtwoord voldoende. Maar hoeveel sites, routers en andere bestemmingen doen dat vandaag? "
Ze zouden het allemaal moeten doen. Zaken als maximum aantal inlogpogingen instellen e.d. zijn wel iets voor de beheerders van een site; gebruikers gaan daar niet over en hebben daar dus meestal weinig invloed op.
Ze zouden het allemaal moeten doen. Zaken als maximum aantal inlogpogingen instellen e.d. zijn wel iets voor de beheerders van een site; gebruikers gaan daar niet over en hebben daar dus meestal weinig invloed op.
Ik zou graag je telefoon als contactnummer geven aan gebruikers van 'alle' sites, routers die kiezen voor een 3-10 x lockout.
Vooral aan studenten John J. Johnson en John Johnson, die zich voor de deadline voor hun tentamen moeten inschrijven.
(Want lockouts gebeuren, soms als 'geintje', maar meer bij mensen die wat dikke vingers hebben, juist de brave borsten die een echt moeilijk password gekozen hebben. Dat leren ze dan wel af.
En natuurlijk bij mensen die een paar keer teveel proberen met de verkeerde usernaam , (kan prima dat je je usernaam van een andere site intikt. Bij faalpogingen controleer je typisch alleen het password, dat je dat toch echt goed intikt.
En mensen met een naam als johnson, smith e.d. hebben natuurlijk vaak naamgenoten met een zeer nabije username die elkaar onderling dan blokkeren )
Soms moet security boven alles, en moet je de belasting op IT support , verloren tijd , boze gebruikers e.d. accepteren.
En soms worden de belangen anders afgewogen.
Kortom, ik ben niet eens met 'ze zouden het _allemaal_ moeten doen' . Soms kun je de nadelen van zo'n policy niet accepteren.
20-06-2014, 22:04 door
Fwiffo
Het kiezen van wachtwoorden kan goed fout gaan bij mensen die per ongeluk hun toetsenbord indeling veranderen ([ctrl]+[shift] onder Windows iirc). Dit komt omdat de meeste wachtwoorden onzichtbaar als '********' worden weergegeven waardoor niet opvalt dat iets anders wordt ingetypt als dat de gebruiker verwacht.
Bij de indeling 'VS Internationaal' krijg je bijvoorbeeld met ["]+[e] -> [ë]. Maar bij de indeling 'VS' gebeurt dit niet.
Met ["]+[ ] krijg je bij 'VS Internationaal' ["] maar bij 'VS' [" ].
Bij de toetsenbord indeling 'Nederlands' wordt het helemaal een ramp met leestekens omdat er flinke verschillen zijn met 'VS Internationaal'!
Voor tekens boven de ascii waarde 127 hangt verder een en ander af van de tekenset die je gebruikt. Dit gaf in de jaren negentig al regelmatig problemen in de pgp nieuwsgroepen. Weer omdat je niet ziet wat je typt. Bruce Schneier heeft geloof ik ooit voorgesteld om wachtwoorden weer te geven bij het intypen. Maar dan moet je wel goed opletten op schoudersurfers, dus dit kan niet overal.
Bij de indeling 'VS Internationaal' krijg je bijvoorbeeld met ["]+[e] -> [ë]. Maar bij de indeling 'VS' gebeurt dit niet.
Met ["]+[ ] krijg je bij 'VS Internationaal' ["] maar bij 'VS' [" ].
Bij de toetsenbord indeling 'Nederlands' wordt het helemaal een ramp met leestekens omdat er flinke verschillen zijn met 'VS Internationaal'!
Voor tekens boven de ascii waarde 127 hangt verder een en ander af van de tekenset die je gebruikt. Dit gaf in de jaren negentig al regelmatig problemen in de pgp nieuwsgroepen. Weer omdat je niet ziet wat je typt. Bruce Schneier heeft geloof ik ooit voorgesteld om wachtwoorden weer te geven bij het intypen. Maar dan moet je wel goed opletten op schoudersurfers, dus dit kan niet overal.
Door Fwiffo: Het kiezen van wachtwoorden kan goed fout gaan bij mensen die per ongeluk hun toetsenbord indeling veranderen ([ctrl]+[shift] onder Windows iirc). Dit komt omdat de meeste wachtwoorden onzichtbaar als '********' worden weergegeven waardoor niet opvalt dat iets anders wordt ingetypt als dat de gebruiker verwacht.
Ja inderdaad, en niet alleen met speciale tekens maar ook met gewone leestekens heb je al dat probleem.
Dwz wat komt er op het scherm als je op de toetsen rechts naast de letters (rondom ENTER) drukt. Dat is bij
de NEDERLANDS layout weer anders dan bij de VS layout.
Er loopt toevallig net een issue hierover op het werk, kennelijk is het zo dat als mensen vanuit thuis werken via een
citrix receiver het allemaal nog complexer wordt. Het schijnt zo te zijn dat deze tijdens het gewone werken de toetsenbord
layout van de sessie gebruikt (en daar is alleen "VS Internationaal" beschikbaar) en als je het scherm locked dan
gebruikt hij voor het invoeren van het password je locale computer keyboard instelling, en die kan dus anders zijn.
Inderdaad wordt dit met Ctrl+Shift getoggled. Ik zou denken ga een keer naar de toetsenbord instellingen en flikker
al die foute layouts weg en haal het vinkje weg bij die Ctrl+Shift hotkey, maar goed dat moet je dan de gebruiker maar
weer uitleggen en dat gaat natuurlijk ook wer bij iedere Windows versie net iets anders.
Door Dick99999: @16:06 door Anoniem
In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog.
Wat nou als je de gebruikers vandaag een 2-factor oplossing geeft? Dan heb je "morgen" toch geen wachtwoord probleemIn de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog.
meer?
Waarom altijd maar vasthouden aan een oude foute keuze?
Door Anoniem:
Waarom altijd maar vasthouden aan een oude foute keuze?
Waarom altijd het oude afkraken en impliciet verkeerd gebruik promoten, omdat er een nieuwe (goede) belofte is?Door Dick99999: @16:06 door Anoniem
In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog.
Wat nou als je de gebruikers vandaag een 2-factor oplossing geeft? Dan heb je "morgen" toch geen wachtwoord probleem meer?In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog.
Waarom altijd maar vasthouden aan een oude foute keuze?
Waarom altijd oude schoenen wegwerpen voordat je nieuwe hebt?
De komende week gebruik ik:
email (pop en imap), Skype ,Marktplaats, ING, eBay, Binckbank, KPN online backup, MS Onedrive, Knab bank, Paypal, en een x-tal andere sites
Zullen we er samen even voor zorgen dat er een (bruikbare en liefst gestandaardiseerde) 2-factor oplossing komt voor die zaken? Of is het toch praktischer en zelfs beter om voor de komende 'week' een - op de situatie afgestemd (zoals offline,online, gebruikte hash) - sterk wachtwoord te promoten voor die zaken?
Ben ik de enige die bij het zien van een blacklist van 63 miljoen woorden denkt.. Mooi dan kan je er al 63 miljoen overslaan als je een brute force attack uitvoert...
Ik vraag me af wat er meer effect heeft, die 63 miljoen blaclisten of die 63 miljoen extra mogelijkheden geven voor de gebruiker.
begrijp me niet verkeerd, ik ben voor een blacklist, maar 1 miljoen zou toch ruim voldoende moeten zijn?
Ik vraag me af wat er meer effect heeft, die 63 miljoen blaclisten of die 63 miljoen extra mogelijkheden geven voor de gebruiker.
begrijp me niet verkeerd, ik ben voor een blacklist, maar 1 miljoen zou toch ruim voldoende moeten zijn?
Door Dick99999:
Waarom altijd oude schoenen wegwerpen voordat je nieuwe hebt?
De komende week gebruik ik:
email (pop en imap), Skype ,Marktplaats, ING, eBay, Binckbank, KPN online backup, MS Onedrive, Knab bank, Paypal, en een x-tal andere sites
Zullen we er samen even voor zorgen dat er een (bruikbare en liefst gestandaardiseerde) 2-factor oplossing komt voor die zaken? Of is het toch praktischer en zelfs beter om voor de komende 'week' een - op de situatie afgestemd (zoals offline,online, gebruikte hash) - sterk wachtwoord te promoten voor die zaken?
Door Anoniem:
Waarom altijd maar vasthouden aan een oude foute keuze?
Waarom altijd het oude afkraken en impliciet verkeerd gebruik promoten, omdat er een nieuwe (goede) belofte is?Door Dick99999: @16:06 door Anoniem
In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog.
Wat nou als je de gebruikers vandaag een 2-factor oplossing geeft? Dan heb je "morgen" toch geen wachtwoord probleem meer?In de praktijk heb je wachtwoorden nodig, nu, vandaag en 'morgen' ook nog.
Waarom altijd maar vasthouden aan een oude foute keuze?
Waarom altijd oude schoenen wegwerpen voordat je nieuwe hebt?
De komende week gebruik ik:
email (pop en imap), Skype ,Marktplaats, ING, eBay, Binckbank, KPN online backup, MS Onedrive, Knab bank, Paypal, en een x-tal andere sites
Zullen we er samen even voor zorgen dat er een (bruikbare en liefst gestandaardiseerde) 2-factor oplossing komt voor die zaken? Of is het toch praktischer en zelfs beter om voor de komende 'week' een - op de situatie afgestemd (zoals offline,online, gebruikte hash) - sterk wachtwoord te promoten voor die zaken?
Dat gebeurd ook, helaas nog niet in Nederland. In Noorwegen bv gebruiken belastingdienst, gemeentes en overheden de authenticatie engine van de bankpassen. Dus kan je je bank calculator gebruiken om in te loggen bij de belastingdienst. Geen geode met een digiD etc die je bijna nooit gebruikt naast je bankcalculator etc die je wel dagelijks gebruikt
Door Anoniem: Ben ik de enige die bij het zien van een blacklist van 63 miljoen woorden denkt.. Mooi dan kan je er al 63 miljoen overslaan als je een brute force attack uitvoert...
Ik vraag me af wat er meer effect heeft, die 63 miljoen blaclisten of die 63 miljoen extra mogelijkheden geven voor de gebruiker.
begrijp me niet verkeerd, ik ben voor een blacklist, maar 1 miljoen zou toch ruim voldoende moeten zijn?
Ik vraag me af wat er meer effect heeft, die 63 miljoen blaclisten of die 63 miljoen extra mogelijkheden geven voor de gebruiker.
begrijp me niet verkeerd, ik ben voor een blacklist, maar 1 miljoen zou toch ruim voldoende moeten zijn?
Pak je rekenmachine en kijk welk percentage 63M is van de zoekruimte .
Peanuts, als het goed is.
Pak ook je rekenmachine (en google) en kijk hoe groot een blacklist wordt als je de som van gelekte passwords , en hoe groot dictionaries met variaties (hello hell0 h3ll0 he77o ) worden.
63M hoeft echt niet gek te zijn.
Komt in de buurt van het voorstel dat elk wachtwoord is toegestaan.
Alleen afhankelijk van de complexiteit wordt er een geldigheidsduur aan toegekent.
Alleen afhankelijk van de complexiteit wordt er een geldigheidsduur aan toegekent.
Door Anoniem: Ben ik de enige die bij het zien van een blacklist van 63 miljoen woorden denkt.. Mooi dan kan je er al 63 miljoen overslaan als je een brute force attack uitvoert...
Ik vraag me af wat er meer effect heeft, die 63 miljoen blaclisten of die 63 miljoen extra mogelijkheden geven voor de gebruiker.
begrijp me niet verkeerd, ik ben voor een blacklist, maar 1 miljoen zou toch ruim voldoende moeten zijn?
Alle vijf-letter-combinaties leveren in kleine letters (of in hoofdletters) al 26^5=11.881.376 mogelijkheden op, laat staan als je kijkt naar én kleine letters én hoofdletters (52^5=380.204.032). De mogelijkheden nemen natuurlijk nog verder toe als je ook cijfers meeneemt in de berekening.Ik vraag me af wat er meer effect heeft, die 63 miljoen blaclisten of die 63 miljoen extra mogelijkheden geven voor de gebruiker.
begrijp me niet verkeerd, ik ben voor een blacklist, maar 1 miljoen zou toch ruim voldoende moeten zijn?
wat zou het Wachtwoord bij code spaces geweest zijn? Enkel een wachtwoord aanpak op kritische punten is al niet acceptable 2fa? lokale verficiatie? waar is de risicoafweging als argument gebleven?
Door Anoniem:
Dat gebeurd ook, helaas nog niet in Nederland. In Noorwegen bv gebruiken belastingdienst, gemeentes en overheden de authenticatie engine van de bankpassen. Dus kan je je bank calculator gebruiken om in te loggen bij de belastingdienst. Geen gedoe met een digiD etc die je bijna nooit gebruikt naast je bankcalculator etc die je wel dagelijks gebruikt
Ik moet er niet aan denken dat ik voor elke login een calculator moet gebruiken. Ik vind de ING aanpak, een sms met de autorisatie code, veel aantrekkelijker. En als de code op mijn telefoon ook nog via de pc-camera herkend wordt, kan ik 95% van mijn logins gemakkelijk doen. [............]
Zullen we er samen even voor zorgen dat er een (bruikbare en liefst gestandaardiseerde) 2-factor oplossing komt voor die zaken? Of is het toch praktischer en zelfs beter om voor de komende 'week' een - op de situatie afgestemd (zoals offline,online, gebruikte hash) - sterk wachtwoord te promoten voor die zaken?
Zullen we er samen even voor zorgen dat er een (bruikbare en liefst gestandaardiseerde) 2-factor oplossing komt voor die zaken? Of is het toch praktischer en zelfs beter om voor de komende 'week' een - op de situatie afgestemd (zoals offline,online, gebruikte hash) - sterk wachtwoord te promoten voor die zaken?
Dat gebeurd ook, helaas nog niet in Nederland. In Noorwegen bv gebruiken belastingdienst, gemeentes en overheden de authenticatie engine van de bankpassen. Dus kan je je bank calculator gebruiken om in te loggen bij de belastingdienst. Geen gedoe met een digiD etc die je bijna nooit gebruikt naast je bankcalculator etc die je wel dagelijks gebruikt
Overigens biedt 2-factor geen bescherming als 'het beschermde' gestolen wordt. Denk bijvoorbeeld aan een wachtwoord kluis. Mooie 2_factor autorisatie, maar de inbreker gaat daar om heen, steelt de kluis en zou alle wachtwoorden kunnen krijgen door brute force van het kluis wachtwoord.
Dick, je denkt na ... (de consumentenbond niet). Het advies om alles in via een passwordmanager te laten regelen geeft een hacker een prima aanvalspunt. Als de kluis dan brak gaat is alles open. Leuk voor black hacking als het om een algmeen tool gaat. Een goed voorbeeld van de sleutel ligt onder de deurmat.
Overigens die SMS aanpak is een voorbeeld van 2fa, het gaat er om dat er twee volledig gescheiden paden zijn.
Overigens die SMS aanpak is een voorbeeld van 2fa, het gaat er om dat er twee volledig gescheiden paden zijn.
Als je de risico's van lokale opslag van wachtwoorden (hoe moet je ze anders onthouden?) afzet tegenover cloud opslag, komt cloud opslag er vrij snel goed uit. Ja het is 1 enkel aanvalspunt. Maar ook als zou de hacker slagen de database te bemachtigen, dan helpt een sterk wachtwoord heel goed, dat is te berekenen: risico vrijwel nul.
Verder kan je werkelijk belangrijke wachtwoorden als bank rekeningen 'bepeperen', Het peper is een te onthouden voor- of achtervoegsel, is hetzelfde voor alle wachtwoorden die peper nodig hebben en de peper staat natuurlijk niet in de kluis. Je moet dus 2 'wachtwoorden' onthouden: de sleutel tot de kluis en de peper.
Verder kan je werkelijk belangrijke wachtwoorden als bank rekeningen 'bepeperen', Het peper is een te onthouden voor- of achtervoegsel, is hetzelfde voor alle wachtwoorden die peper nodig hebben en de peper staat natuurlijk niet in de kluis. Je moet dus 2 'wachtwoorden' onthouden: de sleutel tot de kluis en de peper.
09-07-2014, 00:32 door
Erik van Straten
Door Dick99999: Als je de risico's van lokale opslag van wachtwoorden (hoe moet je ze anders onthouden?) afzet tegenover cloud opslag, komt cloud opslag er vrij snel goed uit.
In elk geval niet bij Roboform, zie http://ramblingrant.co.uk/2014/06/29/how-secure-is-roboform-the-5-minute-challenge/ (bron: http://www.theregister.co.uk/2014/07/03/roboform_security_worries/).Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.