Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
ING wachtwoord
08-07-2015, 18:56 door Anoniem, 56 reacties
ING vraagt eens per jaar aan zijn particuliere "internetbankiers" het wachtwoord te vervangen. Ik gebruik LastPass als wachtwoordgenerator en vraag LastPass ook altijd om speciale tekens. Gisteren ontdekte ik dat ING maar een paar speciale tekens toelaat, waardoor het gebruik van een wachtwoordgenerator als LastPass lastig is. Ik stuurde een mailtje naar de ING waarin ik vroeg waarom ze speciale tekens maar beperkt toelaten. Zojuist kreeg ik het antwoord: "Weet ik niet". Één hoeraatje voor de ING veiligheidsvoorlichting!
Reacties (56)
ING en veiligheid dat is er ver over hé
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Door Anoniem: ING en veiligheid dat is er ver over hé
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
08-07-2015, 22:10 door
karma4
Het is een grote organisatie. Wat er dan speelt is dat iemand wat verzint en dat afhankelijk van zijn macht doorvoert. De uitvoerders hebben enkel een lijstje van regeltjes wat ze moeten doen en waarop de beoordeling gaat. Voldoe aan het adagium "hoe wordt ik een rat". Het antwoord past in die lijn, je mag blij zijn dat er een behoorlijk antwoord gegeven is.
Ze werken met vele systemen en technieken door elkaar, het zou me niets verbazen als de uitgesloten bijzondere tekens daar een gevolg van zijn. https://www.ing.nl/de-ing/veilig-bankieren/5bs-van-veilig-bankieren/bescherm-uw-codes/hoe-sterk-is-uw-wachtwoord.html en: Punt 5 niet ergens op de computer opslaat....
Ze werken met vele systemen en technieken door elkaar, het zou me niets verbazen als de uitgesloten bijzondere tekens daar een gevolg van zijn. https://www.ing.nl/de-ing/veilig-bankieren/5bs-van-veilig-bankieren/bescherm-uw-codes/hoe-sterk-is-uw-wachtwoord.html en: Punt 5 niet ergens op de computer opslaat....
>Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
Door Anoniem:
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Door Anoniem: ING en veiligheid dat is er ver over hé
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
lol @ above...
Tuurlijk, laat ik ook gelijk mijn eigen OS schrijven...
Bijdehandje...
OT:
Ik zal het je nog mooier maken, tot een jaar geleden was je wachtwoord case INsensitive bij ING omdat het teveel helpdesk calls opleverde van ouderen die probeerde te internet bankieren.
Het was niet bekend en geen mens kraaide ernaar.
Is het goed? Nee absoluut niet, maar het laat wel zien dat de security na je password toch op orde is.
Of wij Nederlanders zijn zo armzalig dat we gewoon niet de interesse wekken van cyber criminelen.
Door Anoniem:
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING?
Ik (TS )schreef: Één hoeraatje voor de ING veiligheidsvoorlichting! Waar staat iets over de "gehele ING"?@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING?
Door Anoniem:
Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden. Of een komma toegestaan is, is ambigu: hij staat twee maal in het rijtje toegestane tekens, maar vermoedelijk als scheidingsteken. Vindt maar eens een generator die dezelfde verzameling ondersteunt.
"Bouw je eigen generator". Haha, you are kidding, right? Je verwacht dat een klant van de ING een programma kan schrijven dat x keer een random getal genereert tussen 1 en 70 en het bijbehorende teken ophaalt? Er is momenteel op dit forum een discussie gaande over de moeilijkheid van internetbankieren voor ouderen en laaggeletterden. Jij suggereert wel even het andere uiterste. Tussen twee haakjes: denkend aan ouderen, de strategie van de ING om midden in een transactie de gebruiker te overvallen met de eis van een nieuw wachtwoord, zal niet tot sterke wachtwoorden leiden, om het maar eens understated uit te drukken. Vaak zal het wachtwoord de naam van het laatstgeboren kleinkind worden, ben ik bang.
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
ijler 100 leperd akolei kolkje
Anders dan een limiet, van zeg 4K, tegen buffer overflow attacks, is een maximale wachtwoordlengte volkomen overbodig, omdat wachtwoorden toch als hashes opgeslagen worden. Meeste hashes zijn 256 bits lang. Ik hoop dat de knulligheid van de webpagina geen maat is voor de veiligheid van de ING authenticatie database, want die wordt vast nog wel eens gehackt. In ieder geval gaat de ING ervan uit dat dat zal gebeuren, anders zouden ze geen gezouten hashed opslag (hoop ik toch?) gebruiken.Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
Deze reactie heeft de mijne (TS) gekruist. O gruwel, het zal toch niet waar zijn, plain text?>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
Dit heeft vast te maken met input validate en het voorkomen dat code (script) ingevoerd wordt op invoervelden.
Er van uitgaande dat iedereen op basis van die karakters een true random password van 20 posities ingeeft, krijg je een password sterkte van 122 bits...
Helaas zijn we gewoontedieren, en gebruiken we makkelijk te onthouden wachtwoorden.
Dan blijft er (zeker bij acht posities) maar weinig over.
Als ze nog
Helaas zijn we gewoontedieren, en gebruiken we makkelijk te onthouden wachtwoorden.
Dan blijft er (zeker bij acht posities) maar weinig over.
Door Anoniem: Dit heeft vast te maken met input validate en het voorkomen dat code (script) ingevoerd wordt op invoervelden.
Als ze nog
INSERT 'invoerveld.value' INTO usertabel;
gebruiken wel ja...Als je ergens ziet dat er wachtwoorden geeist worden met allerlei speciale voorwaarden en tekensets dan weet je
dat deze eisen zijn overgenomen uit standaardverhalen, zonder inzicht in de psychologie van de mens.
Van dergelijke eisen wordt het wachtwoord alleen maar ONveiliger, niet veiliger!
dat deze eisen zijn overgenomen uit standaardverhalen, zonder inzicht in de psychologie van de mens.
Van dergelijke eisen wordt het wachtwoord alleen maar ONveiliger, niet veiliger!
Door Anoniem:
lol @ above...
Tuurlijk, laat ik ook gelijk mijn eigen OS schrijven...
Bijdehandje...
OT:
Ik zal het je nog mooier maken, tot een jaar geleden was je wachtwoord case INsensitive bij ING omdat het teveel helpdesk calls opleverde van ouderen die probeerde te internet bankieren.
Het was niet bekend en geen mens kraaide ernaar.
Is het goed? Nee absoluut niet, maar het laat wel zien dat de security na je password toch op orde is.
Of wij Nederlanders zijn zo armzalig dat we gewoon niet de interesse wekken van cyber criminelen.
Door Anoniem:
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Door Anoniem: ING en veiligheid dat is er ver over hé
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
lol @ above...
Tuurlijk, laat ik ook gelijk mijn eigen OS schrijven...
Bijdehandje...
OT:
Ik zal het je nog mooier maken, tot een jaar geleden was je wachtwoord case INsensitive bij ING omdat het teveel helpdesk calls opleverde van ouderen die probeerde te internet bankieren.
Het was niet bekend en geen mens kraaide ernaar.
Is het goed? Nee absoluut niet, maar het laat wel zien dat de security na je password toch op orde is.
Of wij Nederlanders zijn zo armzalig dat we gewoon niet de interesse wekken van cyber criminelen.
Aangezien het blijkbaar nodig is om mensen uit te maken voor dingen, zal ik ook maar mijn bijdrage leveren: Kortzichtige Limburger.
Door Anoniem:
Ik zie ING veiligheidsvoorlichting als een uitingsvorm van een "beleid" dat gevoerd wordt door de ING. Dit representeert als het ware ING in haar geheel.
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden. Of een komma toegestaan is, is ambigu: hij staat twee maal in het rijtje toegestane tekens, maar vermoedelijk als scheidingsteken. Vindt maar eens een generator die dezelfde verzameling ondersteunt.
"Bouw je eigen generator". Haha, you are kidding, right? Je verwacht dat een klant van de ING een programma kan schrijven dat x keer een random getal genereert tussen 1 en 70 en het bijbehorende teken ophaalt? Er is momenteel op dit forum een discussie gaande over de moeilijkheid van internetbankieren voor ouderen en laaggeletterden. Jij suggereert wel even het andere uiterste. Tussen twee haakjes: denkend aan ouderen, de strategie van de ING om midden in een transactie de gebruiker te overvallen met de eis van een nieuw wachtwoord, zal niet tot sterke wachtwoorden leiden, om het maar eens understated uit te drukken. Vaak zal het wachtwoord de naam van het laatstgeboren kleinkind worden, ben ik bang.
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
Door Anoniem:
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING?
Ik (TS )schreef: Één hoeraatje voor de ING veiligheidsvoorlichting! Waar staat iets over de "gehele ING"?@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING?
Ik zie ING veiligheidsvoorlichting als een uitingsvorm van een "beleid" dat gevoerd wordt door de ING. Dit representeert als het ware ING in haar geheel.
Door Anoniem:
Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden. Of een komma toegestaan is, is ambigu: hij staat twee maal in het rijtje toegestane tekens, maar vermoedelijk als scheidingsteken. Vindt maar eens een generator die dezelfde verzameling ondersteunt.
"Bouw je eigen generator". Haha, you are kidding, right? Je verwacht dat een klant van de ING een programma kan schrijven dat x keer een random getal genereert tussen 1 en 70 en het bijbehorende teken ophaalt? Er is momenteel op dit forum een discussie gaande over de moeilijkheid van internetbankieren voor ouderen en laaggeletterden. Jij suggereert wel even het andere uiterste. Tussen twee haakjes: denkend aan ouderen, de strategie van de ING om midden in een transactie de gebruiker te overvallen met de eis van een nieuw wachtwoord, zal niet tot sterke wachtwoorden leiden, om het maar eens understated uit te drukken. Vaak zal het wachtwoord de naam van het laatstgeboren kleinkind worden, ben ik bang.
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
ijler 100 leperd akolei kolkje
Anders dan een limiet, van zeg 4K, tegen buffer overflow attacks, is een maximale wachtwoordlengte volkomen overbodig, omdat wachtwoorden toch als hashes opgeslagen worden. Meeste hashes zijn 256 bits lang. Ik hoop dat de knulligheid van de webpagina geen maat is voor de veiligheid van de ING authenticatie database, want die wordt vast nog wel eens gehackt. In ieder geval gaat de ING ervan uit dat dat zal gebeuren, anders zouden ze geen gezouten hashed opslag (hoop ik toch?) gebruiken.Kijk, dat zijn argumentaties die ik waardeer. Bedankt voor het alsnog geven van je toelichting na mijn wellicht agressief overkomende reactie. Ik ben het zeker met je eens wat betreft het wachtwoordbeleid van de ING. Het is niet slim om de mogelijkheden qua wachtwoordcomplexiteit van de gebruiker te reduceren, omdat deze dan inderdaad via meerdere methodes in kortere tijd te achterhalen zijn.
Zoals je inderdaad zegt is het overvallen van gebruikers met het veranderen van wachtwoorden niet bepaald positief, puur om hetzelfde argument dat jij geeft.
We moeten echter wel in ons achterhoofd houden dat er meerdere stappen nodig zijn om daadwerkelijk transacties met het account van een gebruiker te kunnen maken. (Dit lijkt me wel prioriteit nummer 1). Dat het wachtwoordbeleid slecht is, oké dat hoort niet, maar er zijn meer methoden door de ING geïntroduceerd om te voorkomen dat er misbruik gemaakt wordt van gebruikersaccounts. Ik denk dat het niet mogelijk/heel moeilijk is om informatiebeveiliging toe te passen, waarbij er rekening gehouden wordt met het psychologisch aspect. Ik verwacht ook dat deze "issue" voorlopig nog zal blijven voortbestaan.
Nogmaals, dank voor je toelichting. Vind je ook niet dat je hier veel meer discussie mee kunt voeren dan met enkele regels?
Door Anoniem: Ik gebruik LastPass als wachtwoordgenerator en vraag LastPass ook altijd om speciale tekens. Gisteren ontdekte ik dat ING maar een paar speciale tekens toelaat, waardoor het gebruik van een wachtwoordgenerator als LastPass lastig is.
Dit al gelezen?
https://thehackerblog.com/stealing-lastpass-passwords-with-clickjacking/
10-07-2015, 09:31 door
Dick99999
Door Anoniem:
[....]
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden.
[.....]
LastPass gebruikt niet alle speciale tekens bij het genereren van wachtwoorden. Heb je wel eens een van de volgende tekens gekregen +-.()[]? ?[....]
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden.
[.....]
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
Speciaal voor die 20 teken limiet heb ik naast de standaard lijsten, een lijst met korte woorden (NL3K) opgenomen in mijn wachtzin generator SimThrow (gebaseerd op Diceware principe). Deze lijst levert wachtzinnen zoals (zonder spaties):ijler 100 leperd akolei kolkje
[.....]Gaaf Zeer Tap Sjef Pol
Ik zou die overigens voor een bank wachtwoord nooit gebruiken. Maar voor veel sites is 5 woorden van 4 tekens goed genoeg. En een aardig discussiepunt is of 57 bits van die 5 woorden bij een bank toch niet voldoende veilig is gezien de limiet op login pogingen.Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
Als je dit soort dingen zegt kan je beter je mond houden aangezien je waarschijnlijk niet weet waar je het over hebt.
Hashen heel iets anders dan encrypten. Als je speciale characters aan een password policy toevoegt maak je het alleen maar moeilijker om het password te achterhalen. Daarnaast kan je een hash ook nog salten en het op die manier moeilijker maken om met rainbow tables passwords te achterhalen die gebaseerd zijn op alleen maar alfa numerieke tekens.
Deze regels hebben dus zeker wel waarde in een password policy.
Door Dick99999:
LastPass gebruikt niet alle speciale tekens bij het genereren van wachtwoorden. Heb je wel eens een van de volgende tekens gekregen +-.()[]? ?
Ja dat is mij (=TS) bekend, maar daar heb ik verder geen last van. Ik begrijp overigens niet waarom LastPass niet alle printable ASCII tekens (behalve < en >) gebruikt, het zou veiliger zijn, maar afijn. In antwoord op een andere reactie in deze thread: ik sla mijn ING wachtwoord niet op bij LastPass, maar gebruik LP wel voor andere wachtwoorden, en daarom is het gemakkelijk om LP als wachtwoordgenerator (eigenlijk een nevenfunctie van LP) te gebruiken.LastPass gebruikt niet alle speciale tekens bij het genereren van wachtwoorden. Heb je wel eens een van de volgende tekens gekregen +-.()[]? ?
Door Dick99999:
Speciaal voor die 20 teken limiet heb ik naast de standaard lijsten, een lijst met korte woorden (NL3K) opgenomen in mijn wachtzin generator SimThrow (gebaseerd op Diceware principe). Deze lijst levert wachtzinnen zoals (zonder spaties):
Speciaal voor die 20 teken limiet heb ik naast de standaard lijsten, een lijst met korte woorden (NL3K) opgenomen in mijn wachtzin generator SimThrow (gebaseerd op Diceware principe). Deze lijst levert wachtzinnen zoals (zonder spaties):
Gaaf Zeer Tap Sjef Pol
Ik zou die overigens voor een bank wachtwoord nooit gebruiken. Maar voor veel sites is 5 woorden van 4 tekens goed genoeg. En een aardig discussiepunt is of 57 bits van die 5 woorden bij een bank toch niet voldoende veilig is gezien de limiet op login pogingen.Persoonlijk geloof ik in passphrases die ik kan onthouden, die voor mij iets betekenen. Ik zet er dan wel leestekens
in en zet soms woorden tussen haakjes en kom dan boven de 20 tekens uit. Voor zoiets als het ING wachtwoord
kan ik geen passphrase gebruiken, maar neem ik 20 random ASCII tekens en sla dat dan weer locaal en encrypted op in een bestand beschermd door een passphrase. De ING zou het voor mij een stuk gemakkelijker maken als ze lange wachtwoorden met haakjes, accolades, vraag- uitroep- en isgelijkteken, punt, komma, dubbele punt en puntkomma zouden toestaan.
Ik denk bij veiligheid niet in de eerste plaats aan meerdere loginpogingen, maar aan diefstal van de hele authenticatie database, zoals onlangs gebeurd bij de US Office of Personnel Management en LastPass. Als het dat soort organisaties kan overkomen, waarom een bank niet? Als de hashes in handen van hackers zijn, worden de eisen aan de complexiteit van de wachtwoorden en hun hashes vele ordes van groottes stringenter. Ik heb geen idee wat de ING doet: Salted? SHA256? Keyword stretching? Ik zou het niet weten.
Door Anoniem:
Aangezien het blijkbaar nodig is om mensen uit te maken voor dingen, zal ik ook maar mijn bijdrage leveren: Kortzichtige Limburger.
Kijk, dat zijn argumentaties die ik waardeer. Bedankt voor het alsnog geven van je toelichting na mijn wellicht agressief overkomende reactie. Ik ben het zeker met je eens wat betreft het wachtwoordbeleid van de ING. Het is niet slim om de mogelijkheden qua wachtwoordcomplexiteit van de gebruiker te reduceren, omdat deze dan inderdaad via meerdere methodes in kortere tijd te achterhalen zijn.
Zoals je inderdaad zegt is het overvallen van gebruikers met het veranderen van wachtwoorden niet bepaald positief, puur om hetzelfde argument dat jij geeft.
We moeten echter wel in ons achterhoofd houden dat er meerdere stappen nodig zijn om daadwerkelijk transacties met het account van een gebruiker te kunnen maken. (Dit lijkt me wel prioriteit nummer 1). Dat het wachtwoordbeleid slecht is, oké dat hoort niet, maar er zijn meer methoden door de ING geïntroduceerd om te voorkomen dat er misbruik gemaakt wordt van gebruikersaccounts. Ik denk dat het niet mogelijk/heel moeilijk is om informatiebeveiliging toe te passen, waarbij er rekening gehouden wordt met het psychologisch aspect. Ik verwacht ook dat deze "issue" voorlopig nog zal blijven voortbestaan.
Nogmaals, dank voor je toelichting. Vind je ook niet dat je hier veel meer discussie mee kunt voeren dan met enkele regels?
Door Anoniem:
lol @ above...
Tuurlijk, laat ik ook gelijk mijn eigen OS schrijven...
Bijdehandje...
OT:
Ik zal het je nog mooier maken, tot een jaar geleden was je wachtwoord case INsensitive bij ING omdat het teveel helpdesk calls opleverde van ouderen die probeerde te internet bankieren.
Het was niet bekend en geen mens kraaide ernaar.
Is het goed? Nee absoluut niet, maar het laat wel zien dat de security na je password toch op orde is.
Of wij Nederlanders zijn zo armzalig dat we gewoon niet de interesse wekken van cyber criminelen.
Door Anoniem:
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Door Anoniem: ING en veiligheid dat is er ver over hé
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Die hun 'security' afdeling ja ... slaapt u rustig verder daar ...
Op basis van welke informatie concludeer je dit?
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING? Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
lol @ above...
Tuurlijk, laat ik ook gelijk mijn eigen OS schrijven...
Bijdehandje...
OT:
Ik zal het je nog mooier maken, tot een jaar geleden was je wachtwoord case INsensitive bij ING omdat het teveel helpdesk calls opleverde van ouderen die probeerde te internet bankieren.
Het was niet bekend en geen mens kraaide ernaar.
Is het goed? Nee absoluut niet, maar het laat wel zien dat de security na je password toch op orde is.
Of wij Nederlanders zijn zo armzalig dat we gewoon niet de interesse wekken van cyber criminelen.
Aangezien het blijkbaar nodig is om mensen uit te maken voor dingen, zal ik ook maar mijn bijdrage leveren: Kortzichtige Limburger.
Door Anoniem:
Ik zie ING veiligheidsvoorlichting als een uitingsvorm van een "beleid" dat gevoerd wordt door de ING. Dit representeert als het ware ING in haar geheel.
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden. Of een komma toegestaan is, is ambigu: hij staat twee maal in het rijtje toegestane tekens, maar vermoedelijk als scheidingsteken. Vindt maar eens een generator die dezelfde verzameling ondersteunt.
"Bouw je eigen generator". Haha, you are kidding, right? Je verwacht dat een klant van de ING een programma kan schrijven dat x keer een random getal genereert tussen 1 en 70 en het bijbehorende teken ophaalt? Er is momenteel op dit forum een discussie gaande over de moeilijkheid van internetbankieren voor ouderen en laaggeletterden. Jij suggereert wel even het andere uiterste. Tussen twee haakjes: denkend aan ouderen, de strategie van de ING om midden in een transactie de gebruiker te overvallen met de eis van een nieuw wachtwoord, zal niet tot sterke wachtwoorden leiden, om het maar eens understated uit te drukken. Vaak zal het wachtwoord de naam van het laatstgeboren kleinkind worden, ben ik bang.
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
Door Anoniem:
@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING?
Ik (TS )schreef: Één hoeraatje voor de ING veiligheidsvoorlichting! Waar staat iets over de "gehele ING"?@TS: waarom representeert één medewerker van de ING die wellicht geen zin heeft om daar meer informatie over op te vragen de gehele ING?
Ik zie ING veiligheidsvoorlichting als een uitingsvorm van een "beleid" dat gevoerd wordt door de ING. Dit representeert als het ware ING in haar geheel.
Door Anoniem:
Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Waarom moet je per se "LastPass" als generator gebruiken? Bouw je eigen generator of gebruik er een waar je wel kan filteren op die karakters.
Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt? De door ING toegestane characterset is de volgende deelverzameling van ASCII: A-Za-z0-9.-_!@#$%, dus bijvoorbeeld de ASCII tekens: ()?[]{}&+=^~ zijn verboden. Of een komma toegestaan is, is ambigu: hij staat twee maal in het rijtje toegestane tekens, maar vermoedelijk als scheidingsteken. Vindt maar eens een generator die dezelfde verzameling ondersteunt.
"Bouw je eigen generator". Haha, you are kidding, right? Je verwacht dat een klant van de ING een programma kan schrijven dat x keer een random getal genereert tussen 1 en 70 en het bijbehorende teken ophaalt? Er is momenteel op dit forum een discussie gaande over de moeilijkheid van internetbankieren voor ouderen en laaggeletterden. Jij suggereert wel even het andere uiterste. Tussen twee haakjes: denkend aan ouderen, de strategie van de ING om midden in een transactie de gebruiker te overvallen met de eis van een nieuw wachtwoord, zal niet tot sterke wachtwoorden leiden, om het maar eens understated uit te drukken. Vaak zal het wachtwoord de naam van het laatstgeboren kleinkind worden, ben ik bang.
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
ijler 100 leperd akolei kolkje
Anders dan een limiet, van zeg 4K, tegen buffer overflow attacks, is een maximale wachtwoordlengte volkomen overbodig, omdat wachtwoorden toch als hashes opgeslagen worden. Meeste hashes zijn 256 bits lang. Ik hoop dat de knulligheid van de webpagina geen maat is voor de veiligheid van de ING authenticatie database, want die wordt vast nog wel eens gehackt. In ieder geval gaat de ING ervan uit dat dat zal gebeuren, anders zouden ze geen gezouten hashed opslag (hoop ik toch?) gebruiken.Kijk, dat zijn argumentaties die ik waardeer. Bedankt voor het alsnog geven van je toelichting na mijn wellicht agressief overkomende reactie. Ik ben het zeker met je eens wat betreft het wachtwoordbeleid van de ING. Het is niet slim om de mogelijkheden qua wachtwoordcomplexiteit van de gebruiker te reduceren, omdat deze dan inderdaad via meerdere methodes in kortere tijd te achterhalen zijn.
Zoals je inderdaad zegt is het overvallen van gebruikers met het veranderen van wachtwoorden niet bepaald positief, puur om hetzelfde argument dat jij geeft.
We moeten echter wel in ons achterhoofd houden dat er meerdere stappen nodig zijn om daadwerkelijk transacties met het account van een gebruiker te kunnen maken. (Dit lijkt me wel prioriteit nummer 1). Dat het wachtwoordbeleid slecht is, oké dat hoort niet, maar er zijn meer methoden door de ING geïntroduceerd om te voorkomen dat er misbruik gemaakt wordt van gebruikersaccounts. Ik denk dat het niet mogelijk/heel moeilijk is om informatiebeveiliging toe te passen, waarbij er rekening gehouden wordt met het psychologisch aspect. Ik verwacht ook dat deze "issue" voorlopig nog zal blijven voortbestaan.
Nogmaals, dank voor je toelichting. Vind je ook niet dat je hier veel meer discussie mee kunt voeren dan met enkele regels?
Bijdehandje is niet met namen smijten, maar jij bent aan het discrimineren meneer Anoniem.
Een regio zegt namelijk niets over een persoon mbt digitale security, jouw opmerking over schrijf er zelf een wel, want we zijn niet allemaal programmeur.
Laat vooral totaal het OT comment met rust en gooi met naampjes.
Dat is echt een bijdrage aan dit topic.
Geheel eens met "Ik denk bij veiligheid niet....". Ik vrees dat er eerst een keer een bank gehacked moet worden voordat de wachtwoordlengte (zowel minimale als maximale) vergroot wordt. Het is onbegrijpelijk dat die limieten nog steeds bestaan. Ik heb gelezen dat het stamt uit de tijd dat wachtwoorden als tekst (niet gehashed) in databases werden opgeslagen.
Ik gebruik LastPass ook voor de categorie financiële wachtwoorden. Maar voor mijn gemoedsrust hebben alle belangrijke wachtwoorden een gemeenschappelijk post- of prefix. Hierdoor ontstaat tot op zekere hoogte iets wat ik heb (in Lastpass) en iets wat ik weet (de pre/postfix). Maar het is geen volledige 2-factor autorisatie. Ik moet nu wel 2 zaken onthouden: de master key en de pre/postfix.
Ik gebruik LastPass ook voor de categorie financiële wachtwoorden. Maar voor mijn gemoedsrust hebben alle belangrijke wachtwoorden een gemeenschappelijk post- of prefix. Hierdoor ontstaat tot op zekere hoogte iets wat ik heb (in Lastpass) en iets wat ik weet (de pre/postfix). Maar het is geen volledige 2-factor autorisatie. Ik moet nu wel 2 zaken onthouden: de master key en de pre/postfix.
Door Anoniem:
Keyword stretching? Ik zou het niet weten.
Erratum: "Keyword stretching" moet zijn "Key stretching" (het moeilijker maken van het raden van cryptografische sleutels). Keyword stretching? Ik zou het niet weten.
Topic starter.
tja, het is niet zo gek dat een bank euro, dollar en drachmetekens niet toelaat in wachtwoorden.
Voordat je het weet devalueert de sterkte van het gekozen wachtwoord.
:-)
Voordat je het weet devalueert de sterkte van het gekozen wachtwoord.
:-)
Sorry guys, maar ik zie het probleem niet zo.
Dit is wat ING toestaat:
A: Cijfers: 0 t/m 9
B: Letters: kleine letters (a t/m z) en hoofdletters (A t/m Z)
C: Leestekens: punt (.), koppelteken (-), liggend streepje (_) en uitroepteken (!)
D: Overige tekens: @, #, $ en %
A+B+C+D = 10 + 52 + 4 + 4 = 70 verschillende karakters.
En het wachtwoord mag een lengte hebben van maximaal 20 karakters.
Kun je dus 70^20 = meer dan 7.979.000.000.000.000.000.000.000.000.000.000.000 wachtwoorden mee maken
Dit is een wachtwoordsterkte van ruim 122,5 bits
Maar helaas kan dit niet met de Lastpass generator, want die genereert helaas ook niet ondersteunde special karakters.
Wat Lastpass wél kan, is helemaal geen speciale karakters genereren. ("advanced setting")
In dat geval maak je alleen gebruik van A+B= 62 karakters.
Kun je meer dan 62^20 = 704.400.000.000.000.000.000.000.000.000.000.000 wachtwoorden mee maken
Dit is een wachtwoordsterkte van nog altijd maar liefst 119,5 bits
Na het uitproberen van 7 onjuiste wachtwoorden wordt je door ING geblokkeerd.
De kans dat het iemand lukt om een willekeurig wachtwoord te raden met 7 pogingen is
ongeveer 1 op 100.000.000.000.000.000.000.000.000.000.000.000
Er leven momenteel ca. 7.327.000.000 mensen op aarde.
Zouden zij allemaal één keer proberen op je account in te breken (dus 7 inlogpogingen)
Dan is er ongeveer een kans van 1 op 13.730.000.000.000.000.000.000.000 dat dit iemand gaat lukken.
En vervolgens moeten ze dan ook nog de tancode raden om een transactie te kunnen doen.
Hierbij geldt: al na 3 onjuiste tancodes wordt het internetbankieren geblokkeerd.
Ik zou zeggen: als je zelf geen wachtwoorden kunt bedenken, schakel in Lastpass "special characters" dan maar uit.
Het scheelt je maar 3 bits (van max. 122,5 naar max. 119,5 bits) en dat is nog altijd een respectabel aantal
voor een applicatie waarbij je na 7 pogingen wordt geblokkeerd, en waarbij je ook nog een tancode nodig hebt.
En heb je daarbij ook niet een gebruikersnaam nodig voor het inloggen? Die zullen ze dus ook nog moeten weten.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Je kaart een probleem aan dat eigenlijk helemaal geen probleem is.
In Lastpass gewoon even "special characters" uitvinken, en dus alleen kleine en grote letters en cijfers gebruiken.
Kies 20 karakters, en je bent zo goed als onkraakbaar, ook al gebruik je geen enkel special karakter.
En als je het zelf fijner vindt, vervang je zelf bijv. één of twee tekens van de suggestie van Lastpass met een
"special character" dat door ING is toegestaan.
Dit is wat ING toestaat:
A: Cijfers: 0 t/m 9
B: Letters: kleine letters (a t/m z) en hoofdletters (A t/m Z)
C: Leestekens: punt (.), koppelteken (-), liggend streepje (_) en uitroepteken (!)
D: Overige tekens: @, #, $ en %
A+B+C+D = 10 + 52 + 4 + 4 = 70 verschillende karakters.
En het wachtwoord mag een lengte hebben van maximaal 20 karakters.
Kun je dus 70^20 = meer dan 7.979.000.000.000.000.000.000.000.000.000.000.000 wachtwoorden mee maken
Dit is een wachtwoordsterkte van ruim 122,5 bits
Maar helaas kan dit niet met de Lastpass generator, want die genereert helaas ook niet ondersteunde special karakters.
Wat Lastpass wél kan, is helemaal geen speciale karakters genereren. ("advanced setting")
In dat geval maak je alleen gebruik van A+B= 62 karakters.
Kun je meer dan 62^20 = 704.400.000.000.000.000.000.000.000.000.000.000 wachtwoorden mee maken
Dit is een wachtwoordsterkte van nog altijd maar liefst 119,5 bits
Na het uitproberen van 7 onjuiste wachtwoorden wordt je door ING geblokkeerd.
De kans dat het iemand lukt om een willekeurig wachtwoord te raden met 7 pogingen is
ongeveer 1 op 100.000.000.000.000.000.000.000.000.000.000.000
Er leven momenteel ca. 7.327.000.000 mensen op aarde.
Zouden zij allemaal één keer proberen op je account in te breken (dus 7 inlogpogingen)
Dan is er ongeveer een kans van 1 op 13.730.000.000.000.000.000.000.000 dat dit iemand gaat lukken.
En vervolgens moeten ze dan ook nog de tancode raden om een transactie te kunnen doen.
Hierbij geldt: al na 3 onjuiste tancodes wordt het internetbankieren geblokkeerd.
Ik zou zeggen: als je zelf geen wachtwoorden kunt bedenken, schakel in Lastpass "special characters" dan maar uit.
Het scheelt je maar 3 bits (van max. 122,5 naar max. 119,5 bits) en dat is nog altijd een respectabel aantal
voor een applicatie waarbij je na 7 pogingen wordt geblokkeerd, en waarbij je ook nog een tancode nodig hebt.
En heb je daarbij ook niet een gebruikersnaam nodig voor het inloggen? Die zullen ze dus ook nog moeten weten.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Je kaart een probleem aan dat eigenlijk helemaal geen probleem is.
In Lastpass gewoon even "special characters" uitvinken, en dus alleen kleine en grote letters en cijfers gebruiken.
Kies 20 karakters, en je bent zo goed als onkraakbaar, ook al gebruik je geen enkel special karakter.
En als je het zelf fijner vindt, vervang je zelf bijv. één of twee tekens van de suggestie van Lastpass met een
"special character" dat door ING is toegestaan.
Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
nou ik denk dat je hier een verkeerde aannamen maak. het kan gewoon eenvoudig zijn dat de tabel van de database maar bepaalde max value heeft.
10-07-2015, 17:13 door
waaromdan
Door Anoniem: Dit al gelezen?
https://thehackerblog.com/stealing-lastpass-passwords-with-clickjacking/
https://thehackerblog.com/stealing-lastpass-passwords-with-clickjacking/
Update: After disclosing with the Lastpass folks via their support system and getting a very quick and helpful response this issue is now fixed for all the latest versions of Lastpass on Chrome & Internet Explorer. Kudos to the Lastpass guys for being so quick on patching! The only patch that is not available is for Mozilla Firefox due to Mozilla’s unwillingness to approve the update in a reasonable amount of time.
Door waaromdan:
Update: After disclosing with the Lastpass folks via their support system and getting a very quick and helpful response this issue is now fixed for all the latest versions of Lastpass on Chrome & Internet Explorer. Kudos to the Lastpass guys for being so quick on patching! The only patch that is not available is for Mozilla Firefox due to Mozilla’s unwillingness to approve the update in a reasonable amount of time.
Let nau us ff op joh... ;-PDoor Anoniem: Dit al gelezen?
https://thehackerblog.com/stealing-lastpass-passwords-with-clickjacking/
https://thehackerblog.com/stealing-lastpass-passwords-with-clickjacking/
Update: After disclosing with the Lastpass folks via their support system and getting a very quick and helpful response this issue is now fixed for all the latest versions of Lastpass on Chrome & Internet Explorer. Kudos to the Lastpass guys for being so quick on patching! The only patch that is not available is for Mozilla Firefox due to Mozilla’s unwillingness to approve the update in a reasonable amount of time.
https://www.security.nl/posting/435092/LastPass+voor+Firefox+kwetsbaar+voor+wachtwoorddiefstal
Heb trouwens ook wel een idee waarom niet alle speciale karakters zijn ondersteund bij ING internetbankieren.
Niet alle speciale karakters zijn namelijk op alle toetsenborden en op alle systemen (eenvoudig) te genereren.
Verder zitten niet alle special karakters in ieder type karakterset op dezelfde plaats in de karakter set tabel.
Ooit gebruikte ik eens een "µ" (het karakter "mu") in een wachtwoord met een IE browser.
Later probeerde ik eens in te loggen met een ander systeem met een FF-browser, en ...potvolkoffie...
ik kwam er niet meer in omdat die FF versie een andere karakterset gebruikte of zo!
Ik tiepte wel heel duidelijk een "µ", maar het scherm liet natuurlijk niets zien, want het was een wachtwoord.
Kan dus een boel gelazer geven bij dit soort situaties, en des te meer bij onervaren gebruikers.
De werkwijze van ING om alleen ondersteuning te geven aan special karakters die de meeste systemen goed kunnen verwerken en die gemakkelijk op toetsenborden te vinden zijn en bovendien een "vaste" plaats hebben in
de meest gebruikelijke karakter sets, voorkomt dit soort gelazer.
goeroehoedjes van anoniem 16:38
Door Anoniem: Sorry guys, maar ik zie het probleem niet zo.
[....]
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Je kaart een probleem aan dat eigenlijk helemaal geen probleem is.
In Lastpass gewoon even "special characters" uitvinken, en dus alleen kleine en grote letters en cijfers gebruiken.
Kies 20 karakters, en je bent zo goed als onkraakbaar, ook al gebruik je geen enkel special karakter.
En als je het zelf fijner vindt, vervang je zelf bijv. één of twee tekens van de suggestie van Lastpass met een
"special character" dat door ING is toegestaan.
Mee eens als het 20 willekeurige letters/cijfers zijn. (Dan laat ik wel het 2-de orde effect weg van de verplichting om meerde soorten tekens te gebruiken.) Maar later heeft Anoniem ook nog het probleem van het gebruik van wachtzinnen bij de ING toegevoegd (zie hieronder). Dan loopt de sterkte terug naar ~39 - ~57 bits, met nog steeds een kleine(?) kans dat de Diceware wachtzin van 3 woorden goed geraden wordt binnen 7 pogingen.[....]
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Je kaart een probleem aan dat eigenlijk helemaal geen probleem is.
In Lastpass gewoon even "special characters" uitvinken, en dus alleen kleine en grote letters en cijfers gebruiken.
Kies 20 karakters, en je bent zo goed als onkraakbaar, ook al gebruik je geen enkel special karakter.
En als je het zelf fijner vindt, vervang je zelf bijv. één of twee tekens van de suggestie van Lastpass met een
"special character" dat door ING is toegestaan.
Door Anoniem:
[....]
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
[....]
Nu ik toch bezig ben: ik vind twee dingen knullig in de programmering van de ING pagina: (i) zoals gezegd, de beperking van de ASCII set. (ii) De maximale wachtwoordlengte van 20 tekens. De tweede beperking maakt dat passphrases niet kunnen en dat terwijl het gebruik van diceware wachtwoorden (http://world.std.com/~reinhold/diceware.html) steeds vaker als veilig aanbevolen worden. Voorbeeld van een diceware wachtwoord (30 tekens):
ijler 100 leperd akolei kolkje
[,,,,]
10-07-2015, 21:00 door
GeminiAlpha
Trek je eigen conclusie n.a.v. de letterlijke online ING tekst dd 10/7/2015:
Voor Mijn ING kunt u een wachtwoord maken met de volgende karakters:
Cijfers: 0 t/m 9
Letters: kleine letters (a t/m z) en hoofdletters (A t/m Z)
Leestekens: punt (.), koppelteken (-), liggend streepje (_) en uitroepteken (!)
Overige tekens: @, #, $ en %
Wij adviseren om in ieder geval 4 keer per jaar uw wachtwoord voor Mijn ING te wijzigen. Dat maakt het soms lastig om een wachtwoord te onthouden. Daarom geven wij u 5 tips om een sterk wachtwoord te verzinnen en hoe u ermee om kunt gaan:
1.
Bedenk een zin en gebruik van elk woord de eerste letter. Bijvoorbeeld: 'Ik zag 2 beren broodjes smeren!'. Combineer dit met cijfers en leestekens. Uw wachtwoord wordt dan bijvoorbeeld: '#Iz2bbs!'.
2.
Gebruik geen wachtwoord dat direct aan u te relateren is. Bijvoorbeeld gegevens die op uw sociale netwerken staan vermeld (zoals uw woonplaats, of de naam van uw hond of kinderen).
3.
Verzin een willekeurig woord en vervang letters of woorden door cijfers en speciale tekens. ‘Sesamstraat123’ wordt dan bijvoorbeeld: ‘S3samstr@@T12drie!’
4.
Gebruik niet overal hetzelfde wachtwoord, maar gebruik een apart wachtwoord voor Mijn ING, een apart wachtwoord voor uw e-mail en sociale netwerken en een apart wachtwoord voor andere zaken.
5.
Als u uw wachtwoord moet opschrijven om het te kunnen onthouden, zet er dan niet bij dat dit uw wachtwoord is. Zorg er ook voor dat u het wachtwoord opschrijft en niet ergens op uw computer opslaat.
Belangrijk: Gebruik de wachtwoorden uit deze voorbeelden niet als eigen wachtwoord.
einde ING online tekst dd 10/7/2015 online gekopieerd en geplakt.
Voor Mijn ING kunt u een wachtwoord maken met de volgende karakters:
Cijfers: 0 t/m 9
Letters: kleine letters (a t/m z) en hoofdletters (A t/m Z)
Leestekens: punt (.), koppelteken (-), liggend streepje (_) en uitroepteken (!)
Overige tekens: @, #, $ en %
Wij adviseren om in ieder geval 4 keer per jaar uw wachtwoord voor Mijn ING te wijzigen. Dat maakt het soms lastig om een wachtwoord te onthouden. Daarom geven wij u 5 tips om een sterk wachtwoord te verzinnen en hoe u ermee om kunt gaan:
1.
Bedenk een zin en gebruik van elk woord de eerste letter. Bijvoorbeeld: 'Ik zag 2 beren broodjes smeren!'. Combineer dit met cijfers en leestekens. Uw wachtwoord wordt dan bijvoorbeeld: '#Iz2bbs!'.
2.
Gebruik geen wachtwoord dat direct aan u te relateren is. Bijvoorbeeld gegevens die op uw sociale netwerken staan vermeld (zoals uw woonplaats, of de naam van uw hond of kinderen).
3.
Verzin een willekeurig woord en vervang letters of woorden door cijfers en speciale tekens. ‘Sesamstraat123’ wordt dan bijvoorbeeld: ‘S3samstr@@T12drie!’
4.
Gebruik niet overal hetzelfde wachtwoord, maar gebruik een apart wachtwoord voor Mijn ING, een apart wachtwoord voor uw e-mail en sociale netwerken en een apart wachtwoord voor andere zaken.
5.
Als u uw wachtwoord moet opschrijven om het te kunnen onthouden, zet er dan niet bij dat dit uw wachtwoord is. Zorg er ook voor dat u het wachtwoord opschrijft en niet ergens op uw computer opslaat.
Belangrijk: Gebruik de wachtwoorden uit deze voorbeelden niet als eigen wachtwoord.
einde ING online tekst dd 10/7/2015 online gekopieerd en geplakt.
Door Anoniem: Ik zat midden in een Ideal transactie, dacht je echt dat ik dat zou onderbreken om het internet af te zoeken naar een generator die de characterset van ING ondersteunt?
Prachtig ik zie het nu pas. Midden in een transactie onderbroken door een pop-up om je wachtwoord te veranderen.....
Wacht eens even, hoe weet je zeker dat het niet een hacked pop-up is?
In plaats van je druk je te maken over wachtworodpolicies zou ik maar eens aankaarten dat die onzekerheid met de plicht om dat te veranderen met een pop-up een veel ernstiger problem is. Hee; vreemd midden in een transactie, ik had het enkel bij de eerste keer aanloggen verwacht. Bedoel je het automatisch betalen deel ideal dat via Currence gaat?
Hoe weet je dat het daar niet gehacked is en de pop-up faked?
Het raden van het wachtwoord is niet zo'n groot probleem als je de pincode ( 4cijfers) / pas acceptabel acht. De echte wijzigingen komen pas met dat SMS token door. Daarvoor moet je een geregistreerd toestel bezitten. (imei/card nummer sim telefoon nummer).
Mee eens als het 20 willekeurige letters/cijfers zijn. (Dan laat ik wel het 2-de orde effect weg van de verplichting om meerde soorten tekens te gebruiken.) Maar later heeft Anoniem ook nog het probleem van het gebruik van wachtzinnen bij de ING toegevoegd (zie hieronder). Dan loopt de sterkte terug naar ~39 - ~57 bits, met nog steeds een kleine(?) kans dat de Diceware wachtzin van 3 woorden goed geraden wordt binnen 7 pogingen.
Jawel, Dick99999, geen kritiek daarop. Alleen ben je uiteraard niet verplicht om zulke wachtwoorden bij ING te gebruiken.Maar een leuk uitstapje is het wel. Bijvoorbeeld:
als ING minimaal 8 karakters voor het wachtwoord vereist, dan kom ik uit op 49 bits sterkte.
Dus die Diceware zit met zijn ca. 39 ~ 57 bits dan redelijk in de buurt van de minimale veiligheidseisen van ING.
Beetje "soms wel, soms niet" -kwestie, maar zou geen groot probleem moeten zijn, lijkt mij.
Want zelfs bij een sterkte van 39 bits is de kans nog bijzonder klein dat iemand het binnen 7 pogingen weet te raden.
(kans hierop is ca. 1 op 78,5 miljard ; en om nog even een idee te geven:
de kans dat je met één keer meespelen in de Staatsloterij met slechts één lot meteen de hoofdprijs zou winnen is tegenwoordig al snel 20.000 keer groter dan dat iemand binnen 7 pogingen een wachtwoord van 39 bits sterk raadt...)
@ GeminiAlpha, 21:00u: als je deze url bekijkt dan zie je in het bovenste gedeelte dat je nog iets vergeten bent. ;-)
https://www.ing.nl/de-ing/veilig-bankieren/5bs-van-veilig-bankieren/bescherm-uw-codes/hoe-sterk-is-uw-wachtwoord.html
11-07-2015, 09:51 door
karma4
Even een beetje off-topic
De meeste sytemen zoals internet office werken tegenwoordig met Unicode utf8. Dat is een codering waarbij elk teken 1 to 4 bytes kan gebruiken. https://en.wikipedia.org/wiki/UTF-8
- Het is een breuk met het dogma dat 1 teken 1 byte is. Je moet dat dogma loslaten.
- Het klassieke 7-bit ascii is zo gemapt dat hiervoor nog wel geldt dat 1-byte = 1 char binnen utf8
Als je nu een programma hebt dat geen utf8 gebruikt, veel databases en programmeertalen gaan nog uit van 1-byte is 1 char dan heb je een probleem.
Dat "µ" teken is daar een vorobeeld van. In utf8 worden het 2 bytes terwijl het in een klassieke encoding 1 byte kan zijn op varierende hex waarden/posities. Wat u ziet is NIET wat u krijgt.
Heb trouwens ook wel een idee waarom niet alle speciale karakters zijn ondersteund bij ING internetbankieren.
Niet alle speciale karakters zijn namelijk op alle toetsenborden en op alle systemen (eenvoudig) te genereren.
Verder zitten niet alle special karakters in ieder type karakterset op dezelfde plaats in de karakter set tabel.
Niet alle speciale karakters zijn namelijk op alle toetsenborden en op alle systemen (eenvoudig) te genereren.
Verder zitten niet alle special karakters in ieder type karakterset op dezelfde plaats in de karakter set tabel.
De meeste sytemen zoals internet office werken tegenwoordig met Unicode utf8. Dat is een codering waarbij elk teken 1 to 4 bytes kan gebruiken. https://en.wikipedia.org/wiki/UTF-8
- Het is een breuk met het dogma dat 1 teken 1 byte is. Je moet dat dogma loslaten.
- Het klassieke 7-bit ascii is zo gemapt dat hiervoor nog wel geldt dat 1-byte = 1 char binnen utf8
Als je nu een programma hebt dat geen utf8 gebruikt, veel databases en programmeertalen gaan nog uit van 1-byte is 1 char dan heb je een probleem.
Dat "µ" teken is daar een vorobeeld van. In utf8 worden het 2 bytes terwijl het in een klassieke encoding 1 byte kan zijn op varierende hex waarden/posities. Wat u ziet is NIET wat u krijgt.
Door karma4: De meeste sytemen zoals internet office werken tegenwoordig met Unicode utf8.
Ik was nog nooit op het idee gekomen om de ongebruikelijkere utf-8 tekens in een ww te gebruiken. Maar inderdaad, op mijn nas kan ik zelfs een ww genereren die alleen uit de gekleurde emoticonen uit de utf-8 serie bestaat. Wel omslachtig intikken en deze tekens zijn vast niet vanaf elke computer beschikbaar.
Door karma4: Even een beetje off-topic
De meeste sytemen zoals internet office werken tegenwoordig met Unicode utf8. Dat is een codering waarbij elk teken 1 to 4 bytes kan gebruiken. https://en.wikipedia.org/wiki/UTF-8
- Het is een breuk met het dogma dat 1 teken 1 byte is. Je moet dat dogma loslaten.
- Het klassieke 7-bit ascii is zo gemapt dat hiervoor nog wel geldt dat 1-byte = 1 char binnen utf8
Als je nu een programma hebt dat geen utf8 gebruikt, veel databases en programmeertalen gaan nog uit van 1-byte is 1 char dan heb je een probleem.
Dat "µ" teken is daar een vorobeeld van. In utf8 worden het 2 bytes terwijl het in een klassieke encoding 1 byte kan zijn op varierende hex waarden/posities. Wat u ziet is NIET wat u krijgt.
Lijkt me correct, Karma4. Hoewel ik niet geloof dat er iemand een dogma heeft uitgesproken. ;-) Heb trouwens ook wel een idee waarom niet alle speciale karakters zijn ondersteund bij ING internetbankieren.
Niet alle speciale karakters zijn namelijk op alle toetsenborden en op alle systemen (eenvoudig) te genereren.
Verder zitten niet alle special karakters in ieder type karakterset op dezelfde plaats in de karakter set tabel.
Niet alle speciale karakters zijn namelijk op alle toetsenborden en op alle systemen (eenvoudig) te genereren.
Verder zitten niet alle special karakters in ieder type karakterset op dezelfde plaats in de karakter set tabel.
De meeste sytemen zoals internet office werken tegenwoordig met Unicode utf8. Dat is een codering waarbij elk teken 1 to 4 bytes kan gebruiken. https://en.wikipedia.org/wiki/UTF-8
- Het is een breuk met het dogma dat 1 teken 1 byte is. Je moet dat dogma loslaten.
- Het klassieke 7-bit ascii is zo gemapt dat hiervoor nog wel geldt dat 1-byte = 1 char binnen utf8
Als je nu een programma hebt dat geen utf8 gebruikt, veel databases en programmeertalen gaan nog uit van 1-byte is 1 char dan heb je een probleem.
Dat "µ" teken is daar een vorobeeld van. In utf8 worden het 2 bytes terwijl het in een klassieke encoding 1 byte kan zijn op varierende hex waarden/posities. Wat u ziet is NIET wat u krijgt.
Maar als we dan toch in details willen treden en het naadje van de kous willen weten:
vóór het doordringen van de UTF-8 standaard had je ook nog een tijd van verschillende "uitgebreide ASCII" tabellen".
De officiële ASCII tabel is nl. 7 bits en kan daarom slechts 128 tekens bevatten. Maar men kreeg honger naar meer.
Nu werkten computers in die tijd vooral met bytes (eenheden van 8 bits). Het idee ontstond al snel om het niet gebruikte bit ook maar eens "nuttig te gaan gebruiken", zodat er nog eens 128 tekens konden worden gedefinieerd.
Doch er werden verschillende standaarden ontwikkeld. (Zie onder 8 bit in https://en.wikipedia.org/wiki/ASCII)
Redelijk bekend is de zogenaamde "code page 437" van IBM: https://en.wikipedia.org/wiki/Code_page_437,
die samen met "code page 850": https://en.wikipedia.org/wiki/Code_page_850 in de tijd van MSDOS veel werd gebruikt. Hier is de letter "µ" gedefinieerd in de 8-bits-karaktertabel op plaats 230 (0xE6; tegenwoordig "unicode 00B5").
Maar bij DEC-MCS: https://en.wikipedia.org/wiki/Multinational_Character_Set en het daarvan afgeleide in West-Europa veelgebruikte ISO/IEC8859-1 (tevens eerste html standaard): https://en.wikipedia.org/wiki/ISO/IEC_8859-1 staat de "µ" in de karaktertabel op plaats 181 (0xB5).
Kortom: bij intikken van het µ-karakter wordt bij gebruik van code page 437of 850 één byte "11100110" verzonden,
Bij ISO/IEC8859-1 wordt "10110101" verzonden, en bij unicode UTF-8 de 2 bytes: "11000010 10110101".
En daar kun je dus behoorlijk trammelant mee krijgen als je met verschillende systemen werkt en wanneer je dergelijke minder gangbare karakters in wachtwoorden gebruikt, omdat deze tekens meestal voor het apparaat of voor de software verschillend worden geïnterpreteerd. Wel goed opletten dus met dit soort karakters in wachtwoorden.
Nogmaals goeroehoedjes van anoniem 16:38 alias... ach wat doet het er toe ;-)
P.S.:
Wat overigens ook een rol kan hebben gespeeld voor het beleid van beschikbare karakters bij internetbankieren van ING,
is dat ING ooit is begonnen met "telebankieren", en bij de switch naar internetbankieren alles voor bestaande klanten zoveel mogelijk "backwards compatible" heeft willen houden. (en ook voor zichzelf?...)
Door GeminiAlpha: Trek je eigen conclusie n.a.v. de letterlijke online ING tekst dd 10/7/2015:
........ Daarom geven wij u 5 tips om een sterk wachtwoord te verzinnen en hoe u ermee om kunt gaan:
3. Verzin een willekeurig woord en vervang letters of woorden door cijfers en speciale tekens. ‘Sesamstraat123’ wordt dan bijvoorbeeld: ‘S3samstr@@T12drie!’
4. Gebruik niet overal hetzelfde wachtwoord, maar gebruik een apart wachtwoord voor Mijn ING, een apart wachtwoord voor uw e-mail en sociale netwerken en een apart wachtwoord voor andere zaken.
5. Als u uw wachtwoord moet opschrijven om het te kunnen onthouden, zet er dan niet bij dat dit uw wachtwoord is. Zorg er ook voor dat u het wachtwoord opschrijft en niet ergens op uw computer opslaat.
Belangrijk: Gebruik de wachtwoorden uit deze voorbeelden niet als eigen wachtwoord.
[....]
Dank je GeminiAlpha. Ongelofelijk, maar het staat inderdaad op de ING site......... Daarom geven wij u 5 tips om een sterk wachtwoord te verzinnen en hoe u ermee om kunt gaan:
3. Verzin een willekeurig woord en vervang letters of woorden door cijfers en speciale tekens. ‘Sesamstraat123’ wordt dan bijvoorbeeld: ‘S3samstr@@T12drie!’
4. Gebruik niet overal hetzelfde wachtwoord, maar gebruik een apart wachtwoord voor Mijn ING, een apart wachtwoord voor uw e-mail en sociale netwerken en een apart wachtwoord voor andere zaken.
5. Als u uw wachtwoord moet opschrijven om het te kunnen onthouden, zet er dan niet bij dat dit uw wachtwoord is. Zorg er ook voor dat u het wachtwoord opschrijft en niet ergens op uw computer opslaat.
Belangrijk: Gebruik de wachtwoorden uit deze voorbeelden niet als eigen wachtwoord.
[....]
Punt 3 is een uitermate slecht advies. De ING denk hier alleen aan online aanvallen en alleen op de ING. De gemiddelde wachtwoord gebruiker zal denken als het bij de ING goed is, is het ook goed voor mijn email etc. Sesamstraat123 en alle 'slimme' mutaties zijn in andere gevallen offline makkelijk te kraken. Blijft de vraag waarom er nog geen banken wachtwoord hashes gestolen zijn. Vanwege 2-factor geen interesse ?
Punt 4 is een slecht goedbedoeld advies. Kan gelezen worden als 'je hebt slechts 3 wachtwoorden nodig voor 3 groepen toepassingen (ook 'niet overal' is al zeer verwarrend).
Punt 5 is in principe in strijd met de algemene voorwaarden. Maar ik ben het wel eens met het onherkenbaar opschrijven! (mooi discussiepunt, maar de bank moet dat bewijzen toch?). En de algemene voorwaarden gebruiken de term 'ontcijferen'! En opslaan op de computer (wachtwoord manager) mag niet??
Uit de ING voorwaarden zie www.ing.nl/media/ING_voorwaarden_mijn_ing_tcm162-44070.pdf
U schrijft of slaat uw persoonlijke codes niet op. Of, als u denkt de codes te vergeten, alleen in een voor anderen onherkenbare vorm die alleen door uzelf is te ontcijferen;
('codes' omvatten wachtwoorden, pincodes,TANS,SMS codes etc.)
Door Anoniem: Sorry guys, maar ik zie het probleem niet zo.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Het is een beetje naïef om alleen aan maximaal 7 "online" aanvallen te denken (inlog pogingen vanaf het toetsenbord). Als dat de enige dreiging was hoefde een bank de wachtwoorden niet eens te versleutelen (te hashen).
De echte dreiging komt van "offline" aanvallen. Denk eens aan het volgende scenario:
1. De bank heeft een authenticatie database met een record voor iedere klant bestaande uit drie velden: (i) gebruikersnaam (niet gehashd) (ii) Veel gebruikers hebben een a4tje met tan codes, de bank heeft een kopie hiervan die in de database staat (ongehashd) (iii) Wachtwoord (gehashd).
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
3. De hacker kent het hashing algoritme, en gaat aan de slag met het raden van het wachtwoord.
Zie http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ hoe ver een kraker kan komen. Bijvoorbeeld de wachtwoorden "qeadzcwrsfxv1331" en "momof3g8kids" zijn gekraakt.
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Door Anoniem:
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
Daar zal de bank best wel goede maatregelen tegen genomen hebben. De bank is geen prutserige webwinkel die
gratis PHP software draait waarin het barst van de SQL injection attacks en andere lekken die keer op keer tot
dit soort inbraken leiden. Er zijn geen aanwijzingen dat de gebruikers database van ING door hackers gedownload
is. I.t.t. die van miep de vriendelijke webwinkel om de hoek.
Door Anoniem:
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Ja ALS ALS ALS. Als de hemel naar beneden valt hebben we allemaal een blauwe hoed.
Maar ALS de ING wachtwoorden gehacked zijn DAN zijn de TAN codes nog niet gestolen.
Daarom heet het ook 2-factor authenticatie en daarom wordt het ook gebruikt.
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Door Anoniem:
Daar zal de bank best wel goede maatregelen tegen genomen hebben. De bank is geen prutserige webwinkel die
gratis PHP software draait waarin het barst van de SQL injection attacks en andere lekken die keer op keer tot
dit soort inbraken leiden. Er zijn geen aanwijzingen dat de gebruikers database van ING door hackers gedownload
is. I.t.t. die van miep de vriendelijke webwinkel om de hoek.
Ja ALS ALS ALS. Als de hemel naar beneden valt hebben we allemaal een blauwe hoed.
Maar ALS de ING wachtwoorden gehacked zijn DAN zijn de TAN codes nog niet gestolen.
Daarom heet het ook 2-factor authenticatie en daarom wordt het ook gebruikt.
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Door Anoniem:
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
Daar zal de bank best wel goede maatregelen tegen genomen hebben. De bank is geen prutserige webwinkel die
gratis PHP software draait waarin het barst van de SQL injection attacks en andere lekken die keer op keer tot
dit soort inbraken leiden. Er zijn geen aanwijzingen dat de gebruikers database van ING door hackers gedownload
is. I.t.t. die van miep de vriendelijke webwinkel om de hoek.
Door Anoniem:
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Ja ALS ALS ALS. Als de hemel naar beneden valt hebben we allemaal een blauwe hoed.
Maar ALS de ING wachtwoorden gehacked zijn DAN zijn de TAN codes nog niet gestolen.
Daarom heet het ook 2-factor authenticatie en daarom wordt het ook gebruikt.
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Beste anoniem, het valt me op dat een zekere anoniem een aantal keren rode-kruis aan het spelen is voor de ING.
Hieruit trek ik de voorzichtige conclusie dat u :
a) Werkt bij de ING
b) Bij de security afdeling werkt
c) In ieder geval aangeeft welke software de ING niet draait
d) Vergeet dat in de USA , ik meen bij de FBI/Defensie ? Hele databases zijn gestolen, hetgeen ook geldt voor een bedrijf als het Hacking-Team.
Ergo niets is veilig !
Ook de beveiliging van de ING niet.
Door Anoniem:
Daar zal de bank best wel goede maatregelen tegen genomen hebben. De bank is geen prutserige webwinkel die
gratis PHP software draait waarin het barst van de SQL injection attacks en andere lekken die keer op keer tot
dit soort inbraken leiden. Er zijn geen aanwijzingen dat de gebruikers database van ING door hackers gedownload
is. I.t.t. die van miep de vriendelijke webwinkel om de hoek.
Ja ALS ALS ALS. Als de hemel naar beneden valt hebben we allemaal een blauwe hoed.
Maar ALS de ING wachtwoorden gehacked zijn DAN zijn de TAN codes nog niet gestolen.
Daarom heet het ook 2-factor authenticatie en daarom wordt het ook gebruikt.
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Door Anoniem:
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
Daar zal de bank best wel goede maatregelen tegen genomen hebben. De bank is geen prutserige webwinkel die
gratis PHP software draait waarin het barst van de SQL injection attacks en andere lekken die keer op keer tot
dit soort inbraken leiden. Er zijn geen aanwijzingen dat de gebruikers database van ING door hackers gedownload
is. I.t.t. die van miep de vriendelijke webwinkel om de hoek.
Door Anoniem:
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Ja ALS ALS ALS. Als de hemel naar beneden valt hebben we allemaal een blauwe hoed.
Maar ALS de ING wachtwoorden gehacked zijn DAN zijn de TAN codes nog niet gestolen.
Daarom heet het ook 2-factor authenticatie en daarom wordt het ook gebruikt.
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Dat als als als, is tegenwoordig wel typisch in de Security wereld. Net als in de IT worden er problemen gemaakt van zaken die geen probleem hoeven te zijn of waarvan er soms al helemaal geen probleem bestaat. Ik kwam er ook achter dat ik geen spaties in mijn ING wachtwoord kan gebruiken, tja daar zou ik mee heel erg druk over kunnen maken maar dan neem ik gewoon een paar andere random karakters waardoor het wachtwoord langer en weer moeilijker te kraken valt.
Niet alles is een probleem of hoeft een probleem van gemaakt te worden.
Door Anoniem:
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Lees nou eens dat stuk in Ars Technica over wachtwoord kraken en je zal zien dat een sterk wachtwoord wél een wapen is tegen aanvallers. Veel wachtwoorden zijn te kraken, maar niet alle.Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
12-07-2015, 17:42 door
karma4
Door SPlid: ... Ergo niets is veilig ! Ook de beveiliging van de ING niet.
Eens. - Het DDOS verhaal (2013) waarbij men van niets wist ondanks dat het oude koek is.
- Het gedoe met big data waar alle klantgegevens (email en veel meer) zo makkelijk bij elkaar gebracht worden.
Wat je nog meer kan zien:
Dat is niet alleen met interenen maar ook met inhuur b.v.: http://scyfer.nl/ing-hired-scyfer-to-improve-predictive-analytics-in-next-best-actions/ Werkplekbeheer werd/wordt door ATOS gedaan inclusief alle security. Het beleid is outsourcen van ING security. De policies en monitoring is dan meer twijfelachtig van kwaliteit. http://www.computable.nl/artikel/nieuws/outsourcing/4999818/1276946/ing-wil-atos-inwisselen-voor-fujitsu.html . Er staat zo'n opmerking tussen in de reacties dat de security door polen gedaan wordt.
Ze zullen inderdaad een simpele LAMP stack niet gebruiken voor de hele keten van betalingsverkeer. Er zijn vele duizenden servers (midrange) en mainframes in eigen datacenters die via data-bussen aan elkaar gekoppeld worden.
Als er ergens wat omvalt en dat gebeurt nog wel eens dan weten ze niet goed hoe het aan elkaar geknoopt is en wat er verbeterd moet worden. https://www.allestoringen.nl/storing/ing
Door Anoniem:
Ik kan je aanraden eens te proberen wat INZICHT te krijgen en niet klakkeloos anderen na te praten en over te schrijven.Door Anoniem:
Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Lees nou eens dat stuk in Ars Technica over wachtwoord kraken en je zal zien dat een sterk wachtwoord wél een wapen is tegen aanvallers. Veel wachtwoorden zijn te kraken, maar niet alle.Als je er vanuit gaat dat alles gestolen kan worden dan is een moeilijk wachtwoord daar ook geen wapen tegen.
En zoals het er nu voor staat maken eisen aan wachtwoorden de situatie alleen maar slechter.
Er werd hier gesteld (zonder basis overigens) dat ING de wachtwoorden in plaintext opslaat.
Als dat zo is dan maakt het NIETS uit of je wachtwoord sterk is of niet, als die info zou lekken. En voor brute force
attacks maakt het zowizo niets uit. De doorslaggevende factor is dan dat je een sterk wachtwoord moet opschrijven
in plaats van onthouden, dus dan is de beveiliging juist slechter.
M.a.w. denk ZELF na in plaats van dat aan anderen over te laten die het over andere situaties hebben.
12-07-2015, 20:23 door
karma4
Door Anoniem: De doorslaggevende factor is dan dat je een sterk wachtwoord moet opschrijven
in plaats van onthouden, dus dan is de beveiliging juist slechter.
M.a.w. denk ZELF na in plaats van dat aan anderen over te laten die het over andere situaties hebben.
in plaats van onthouden, dus dan is de beveiliging juist slechter.
M.a.w. denk ZELF na in plaats van dat aan anderen over te laten die het over andere situaties hebben.
Heb je daarover nagedacht?
Tegenvoorbeeld: enveloppenprocedure opgeslagen, lieftst door een derde, in een fysiek afgesloten plaats.
http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf 3.1.1 last section.
Door Anoniem:
Het is een beetje naïef om alleen aan maximaal 7 "online" aanvallen te denken (inlog pogingen vanaf het toetsenbord). Als dat de enige dreiging was hoefde een bank de wachtwoorden niet eens te versleutelen (te hashen).
De echte dreiging komt van "offline" aanvallen. Denk eens aan het volgende scenario:
1. De bank heeft een authenticatie database met een record voor iedere klant bestaande uit drie velden: (i) gebruikersnaam (niet gehashd) (ii) Veel gebruikers hebben een a4tje met tan codes, de bank heeft een kopie hiervan die in de database staat (ongehashd) (iii) Wachtwoord (gehashd).
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
3. De hacker kent het hashing algoritme, en gaat aan de slag met het raden van het wachtwoord.
Zie http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ hoe ver een kraker kan komen. Bijvoorbeeld de wachtwoorden "qeadzcwrsfxv1331" en "momof3g8kids" zijn gekraakt.
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Door Anoniem: Sorry guys, maar ik zie het probleem niet zo.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Het is een beetje naïef om alleen aan maximaal 7 "online" aanvallen te denken (inlog pogingen vanaf het toetsenbord). Als dat de enige dreiging was hoefde een bank de wachtwoorden niet eens te versleutelen (te hashen).
De echte dreiging komt van "offline" aanvallen. Denk eens aan het volgende scenario:
1. De bank heeft een authenticatie database met een record voor iedere klant bestaande uit drie velden: (i) gebruikersnaam (niet gehashd) (ii) Veel gebruikers hebben een a4tje met tan codes, de bank heeft een kopie hiervan die in de database staat (ongehashd) (iii) Wachtwoord (gehashd).
2. De database wordt gedownload door een hacker zonder dat de bank het merkt.
3. De hacker kent het hashing algoritme, en gaat aan de slag met het raden van het wachtwoord.
Zie http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ hoe ver een kraker kan komen. Bijvoorbeeld de wachtwoorden "qeadzcwrsfxv1331" en "momof3g8kids" zijn gekraakt.
Als de bank van niets weet, jouw wachtwoord gekraakt is en tegelijk je gebruikersnaam en tan codes gestolen zijn, mag je zelf de rest verzinnen (sorry guy).
Eerst even voor de goede orde:
Dit topic ging in de eerste plaats over het gemis van ondersteuning voor een aantal special karakters in wachtwoorden van
ING internetbankieren, en de hiermee samenhangende problemen dat:
1. "Lastpass" wachtwoorden maakt met special karakters die niet door ING internetbankieren worden geaccepteerd
2. De sterkte van het wachtwoord hierdoor afneemt, hetgeen T.S. kennelijk ook min of meer een probleem vindt
3. Dat ING helpdesk "niet weet" waarom er niet meer special karakters worden ondersteund, en verder geen actie neemt.
Maar wat mij betreft is dit niet zo'n probleem want (samengevat antwoord):
1. je kan Lastpass zo configureren dat hij geen enkel special karakter meer produceert, maar wel alle letters en cijfers
2. de max. theoretische sterkte van het wachtwoord neemt hierdoor af van ca. 122,5 bit naar 119,5 bit,
3. aangetoond dat hier mee valt te leven, en dat het daarom niet nodig is om je druk over te maken:
Mijn conclusie: de "problemen" 1 & 2 & 3 zijn in feite geen probleem. Dit heb ik in die fase als volgt uitgedrukt:
Sorry guys, maar ik zie het probleem niet zo.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Echt, jullie zoeken hier spijkers op laag water. Ik kan me best voorstellen dat ING er niet zo zwaar aan tilt.
Vervolgens reageer je daar op een gegeven moment op met bovenstaand "quoted" bericht,
waarin je er blijk van geeft dat je 119,5 bit wachtwoordsterkte onvoldoende vindt voor ING internetbankieren,
omdat het volgens jou reëel is dat de database op de server buitgemaakt zou kunnen worden, met alle gevolgen van dien.
Je schildert vervolgens een "worst case" scenario en haalt daarna het voorbeeld van arstechnica aan. Right?
Om met het laatste te beginnen:
a) Het voorbeeld van arstechnica uit 2013 gaat over wachtwoorden gehasht met MD5. Dit is een hopeloos verouderd hashing algoritme dat al sinds 1996 in opspraak is, en in 2010 officieel als onbruikbaar is verklaard.
Dit behoort en kan nooit worden gecorrigeerd met langere of complexere wachtwoorden , maar dient te worden bestreden met betere hashes bijv. sha-2. Het moge duidelijk zijn dat dit een verantwoordelijkheid van de bank is, en is iets waar men bij security-audits oog voor zou moeten hebben. (bijna ondenkbaar dat hier anno 2015 door professionals niet op zou worden gelet). Het heeft nauwelijks of geen zin om dit euvel te lijf te gaan met complexere of langere wachtwoorden.
b) Voorkomen van inbraak en de detectie hiervan is eveneens een verantwoordelijkheid van de bank.
Je mag verwachten dat banken daar veel aandacht aan besteden, dus inbreken zal vast niet gemakkelijk gaan.
Maar helemaal ongelijk heb je niet:
uiteraard bestaat er altijd een kansje dat er toch een database (of een deel ervan) wordt gecompromitteerd.
Echter goed gezouten wachtwoorden zullen niet snel bederven: het is moeilijk te herleiden tot het wachtwoord.
Het duurt meestal wel een aantal jaren (of maanden als men mazzel heeft) voordat men daar achter is.
Dit probleem is simpel op te lossen door je wachtwoord regelmatig te wijzigen, bijv. elke drie maanden.
Aan het belang van periodiek veranderen van wachtwoorden wordt zo te zien door ING gelukkig al aandacht besteed,
hoewel het raadzaam zou zijn om zoiets voor iedereen verplicht te stellen, en op een goede manier te automatiseren.
(voor zover dit al niet gebeurt)
c) Maar stel dat het bijna ondenkbare scenario zich tóch voordoet dat een kwaadwillende hacker onopgemerkt een gigantische inbraak heeft kunnen plegen waarbij zowel gebruikersnamen als wachtwoorden als tancodes zijn buitgemaakt, en nog met MD5 zijn gehasht ook (of zelfs helemaal niet...)
Dan is een complexer wachtwoord ook geen garantie meer dat je gevrijwaard blijft (misschien maakt het je juist extra interessant...) en verder is het onwaarschijnlijk dat er daarna maar één persoon zal worden aangevallen. De hoeveelheid meldingen en o.a. de ontvangende bankrekeningnummers maken dan al snel duidelijk dat er iets heel erg mis is.
Alles wordt direct geblokkeerd, er wordt onderzoek gedaan, de slachtoffers krijgen hun geld terug, probleem opgelost.
Behalve dan, dat getroffen klanten erg geschrokken kunnen zijn, het vertrouwen in de bank is geschaad, en men daarom misschien een andere bank overweegt. En dus zou een bank wel gek zijn om het zo ver te laten komen. Toch?
(hoewel... het zijn en blijven banken natuurlijk...) ;-P Maar hoe dan ook: klant wordt schadeloos gesteld,
en ook een overdreven complex wachtwoord is onvoldoende bescherming in zo'n situatie.
En verder maar weer een stapel goeroehoedjes van anoniem 16:38 ;-)
P.S.:
1. Anoniem Vandaag, 12:37 is een andere anoniem, maar ben het wel eens met de strekking
2. Ik ben geen ING-promotor, maar vind af en toe dat men zaken beter en genuanceerder in perspectief moet leren zien,
(incl. mijzelf, dus als je duidelijk en onomstreden kunt aantonen dat ik er flink naast zit, dan hoor ik het graag!)
Ook ben ik van mening dat men op dit forum vaak vergeet om een gedegen risicoanalyse te maken op basis van de hele situatie, waar details het verschil kunnen maken. (maar dit is misschien ook vakwerk; dus niet iedereen kan dit zomaar,
en er heerst ook meestal een gebrek aan informatie om het grondig te kunnen doen).
Misschien dat er hierdoor nogal gemakkelijk te snel en te simpel en te kortzichtig en te hard wordt geoordeeld,
te weinig genuanceerd, en te slecht gedoseerd.
Gelukkig dat de discussies die hierdoor ontstaan ook best wel weer leerzaam zijn, en soms ook heerlijk "funny". :-)
("een dag niet gelachen is een dag niet geleefd")
ergo niets is veilig. Ook de beveiliging van de ING niet.
Volstrekt juist, maar de discussie ging meende ik over de eventuele noodzaak van nog complexere en/of langere wachtwoorden, en ik geloof dat als het er op aankomt dat je daar niet zoveel beter mee af bent. M.a.w.: de meerwaarde van nóg complexere en/of langere wachtwoorden is imho in deze specifieke toepassing
(d.w.z.: ING-internetbankieren ) gering, en weegt hoogst waarschijnlijk niet op tegen de praktische ongemakken.
(dit is slechts één aspect van het internetbankieren van ING dat hier onder de loep is genomen,
en zegt niets over ING als geheel, en of de werkplekken van het personeel wel goed onderhouden worden, etc. etc...)
13-07-2015, 08:11 door
karma4
Door Anoniem: Eerst even voor de goede orde:
Dit topic ging in de eerste plaats over het gemis van ondersteuning voor een aantal special karakters in wachtwoorden van
ING internetbankieren, en de hiermee samenhangende problemen .....:
Niet eens: De vraag die je daarbij moet stellen is die vraag wel het juiste probleem of .. gaat het om sypmtoombestrijding en is er wat anders. Een stukje probleemanalyse. Dit topic ging in de eerste plaats over het gemis van ondersteuning voor een aantal special karakters in wachtwoorden van
ING internetbankieren, en de hiermee samenhangende problemen .....:
b) Voorkomen van inbraak en de detectie hiervan is eveneens een verantwoordelijkheid van de bank.
Je mag verwachten dat banken daar veel aandacht aan besteden, dus inbreken zal vast niet gemakkelijk gaan.
Wat nu als het tegendeel het geval is? Die onderbouwing is er wel:
Ze hadden met de NVB richtlijnen opgesteld voor de computer thuis (internet access) die zo uitgelegd konden worden dat de consument maar moest aantonen dat zijn apparatuur op orde was. Het zou nooit aan de bank liggen.
Dit probleem is simpel op te lossen door je wachtwoord regelmatig te wijzigen, bijv. elke drie maanden.
Aan het belang van periodiek veranderen van wachtwoorden wordt zo te zien door ING gelukkig al aandacht besteed,
hoewel het raadzaam zou zijn om zoiets voor iedereen verplicht te stellen, en op een goede manier te automatiseren.
(voor zover dit al niet gebeurt)
Doe eens een risicoanalyse: Het lijkt me het zwakke punt wat misbruikt kan worden door malware.
Dit punt bij transacties (ideal) oppakken en dan die verplichting simuleren. Als gebruiker niet eenvoudig te herkennen of het echt ING is of niet. Gebruiker staat onder druk van de transactie, wil snel door.
Een beetje meer social engineering en je kunt dat mogelijk ook wel met internetbankieren en de app zoiets doen.
P.S.:
2. Ik ben geen ING-promotor, maar vind af en toe dat men zaken beter en genuanceerder in perspectief moet leren zien,
(incl. mijzelf, dus als je duidelijk en onomstreden kunt aantonen dat ik er flink naast zit, dan hoor ik het graag!)
Ook ben ik van mening dat men op dit forum vaak vergeet om een gedegen risicoanalyse te maken op basis van de hele situatie, waar details het verschil kunnen maken. .... ("een dag niet gelachen is een dag niet geleefd" Phil Bosmans. )
Het is (onaangekondigd) dat gedwongen wachtwoord veranderen midden in een transactie (ideal?) dat vergeten is.
[M.a.w.: de meerwaarde van nóg complexere en/of langere wachtwoorden is imho in deze specifieke toepassing
(d.w.z.: ING-internetbankieren ) gering, en weegt hoogst waarschijnlijk niet op tegen de praktische ongemakken.
(dit is slechts één aspect van het internetbankieren van ING dat hier onder de loep is genomen,
en zegt niets over ING als geheel, en of de werkplekken van het personeel wel goed onderhouden worden, etc. etc...)
Wel eens, het is te ver afgewaald van de oorspronkleijke vraag
Niet eens, als je over misbruik risicoanalyse wil denken moet je ook die andere gevallen willen kunnen zien.
Wel eens, langere en moeilijkere wachtwoorden helpen niet, Het niet voor niets dat de 2fa op de kritische acties zit. Tan scanner of wat dan ook. Daarvoor moet je iets anders hebben/weten (pincode card telefoon)
De topic starter hier. Voor alle duidelijkheid nog een keer: ik zat op mijn PC (niet smartphone of tablet) een betaling te doen via iDeal. Zoals bekend schakelt iDeal je tijdens de transactie door naar de bank van je keuze. In mijn geval dus ING. Ik kon bij de ING niet binnenkomen voor ik een nieuw wachtwoord ingesteld had. Normaal doe ik dat soepel met LastPass, maar nu weigerde ING een wachtwoord met & (ampersand) erin. Ik heb dat zelf ad hoc aangepast door & te vervangen door _, wat ik kon doen omdat ik weet hoe ik van LastPass naar een editor moet kopiëren (hoeveel klanten van de ING weten dit?).
Maar omdat ik het knullig vond dat niet alle printable ASCII tekens van 32 (ja ook spatie) tot en met 126 (~), die alle op westerse toetsenborden staan, toegestaan zijn, waagde ik er een mailtje naar de ING aan. Ik vond hun antwoord koddig genoeg om het hier even kort te melden. Dat is alles.
Gaande deze discussie is tot mij doorgedrongen dat het gebruikersvriendelijker zou zijn als ING op een of andere manier (SMS, mail?) een vooraankondiging zou doen dat het wachtwoord binnen een paar dagen gewijzigd moet worden. Verder heb ik zelf een voorkeur voor wachtzinnen (redelijk veilig en te onthouden), dus voor mij zou de ING meer tekens en spaties toe mogen laten, maar ik vind het geen "big deal". Tenslotte: het loutere feit dat organisaties wachtwoorden salten en hashen betekent dat zij rekening houden met een eventuele diefstal van hun authenticatie gegevens, hoewel ze uiteraard deze diefstal met alle macht zullen proberen te voorkomen.
Maar omdat ik het knullig vond dat niet alle printable ASCII tekens van 32 (ja ook spatie) tot en met 126 (~), die alle op westerse toetsenborden staan, toegestaan zijn, waagde ik er een mailtje naar de ING aan. Ik vond hun antwoord koddig genoeg om het hier even kort te melden. Dat is alles.
Gaande deze discussie is tot mij doorgedrongen dat het gebruikersvriendelijker zou zijn als ING op een of andere manier (SMS, mail?) een vooraankondiging zou doen dat het wachtwoord binnen een paar dagen gewijzigd moet worden. Verder heb ik zelf een voorkeur voor wachtzinnen (redelijk veilig en te onthouden), dus voor mij zou de ING meer tekens en spaties toe mogen laten, maar ik vind het geen "big deal". Tenslotte: het loutere feit dat organisaties wachtwoorden salten en hashen betekent dat zij rekening houden met een eventuele diefstal van hun authenticatie gegevens, hoewel ze uiteraard deze diefstal met alle macht zullen proberen te voorkomen.
Nog een keer topic starter: ik keek nog een keer naar LastPass en zag dat ik het veel te moeilijk deed. Je kan in het LastPass schermpje waarin het gegenereerde wachtwoord staat gewoon editen. Ik had daar direct & door _ kunnen vervangen. Dom, dom!
Door Anoniem:
Als je dit soort dingen zegt kan je beter je mond houden aangezien je waarschijnlijk niet weet waar je het over hebt.
Hashen heel iets anders dan encrypten. Als je speciale characters aan een password policy toevoegt maak je het alleen maar moeilijker om het password te achterhalen. Daarnaast kan je een hash ook nog salten en het op die manier moeilijker maken om met rainbow tables passwords te achterhalen die gebaseerd zijn op alleen maar alfa numerieke tekens.
Deze regels hebben dus zeker wel waarde in een password policy.
Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
Als je dit soort dingen zegt kan je beter je mond houden aangezien je waarschijnlijk niet weet waar je het over hebt.
Hashen heel iets anders dan encrypten. Als je speciale characters aan een password policy toevoegt maak je het alleen maar moeilijker om het password te achterhalen. Daarnaast kan je een hash ook nog salten en het op die manier moeilijker maken om met rainbow tables passwords te achterhalen die gebaseerd zijn op alleen maar alfa numerieke tekens.
Deze regels hebben dus zeker wel waarde in een password policy.
Hashen is idd iets heel anders dan encrypten.
Laat wel zien dat JIJ niet waar je het overhebt en uberhaupt zeer waarschijnlijk
niks dergelijks geprogrammeerd hebt.
Een gegeven pass: String Hash je eerst. Dan maakt de lengte van het aantal te gebruiken karakters dus niks meer uit.
Wat je er daarna mee doet mag je helemaal zelf weten.
Door Anoniem:
De password length verminderen naar slechts 20 Characters heeft absoluut geen waarde.
Lees dit even door als je het niet meer weet en geen volkomen onzin begin te spuien.
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Deze regels hebben dus zeker wel waarde in een password policy.
>Overige tekens: @, #, $ en %
Deze regels hebben dus zeker wel waarde in een password policy.
De password length verminderen naar slechts 20 Characters heeft absoluut geen waarde.
Lees dit even door als je het niet meer weet en geen volkomen onzin begin te spuien.
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
************************************************************************************************************************************
Dan moet je bij bijna iedere TopicStarter tot aan vervelends toe elke keer eerst vragen "en wat bedoel je daar nou precies mee?" Dit is een forum. Als een TopicStarter ziet dat het de verkeerde kant uit gaat, blijft hij i.h.a. niet zwijgen.
Op basis van het topic van T.S én https://www.security.nl/posting/435037 dat klaarblijkelijk ook door TS is
geschreven, plus daarbij de stand van de discussie op dat moment en een stukje inlevingsvermogen, is wel te concluderen dat zoiets op dat moment aan de orde was. Dat kan niemand ontkennen.
Maar T.S. heeft inmiddels een nadere toelichting gegeven op wat hij in de kern precies bedoelde, waarvoor dank!
*********************************************************************************************************************************************
b) Voorkomen van inbraak en de detectie hiervan is eveneens een verantwoordelijkheid van de bank.
Je mag verwachten dat banken daar veel aandacht aan besteden, dus inbreken zal vast niet gemakkelijk gaan.
Niet eens: Je spreekt een verwachting uit dat ze het wel zullen doen, niet onderbouwd.
Wat nu als het tegendeel het geval is? Die onderbouwing is er wel:
Ze hadden met de NVB richtlijnen opgesteld voor de computer thuis (internet access) die zo uitgelegd konden worden dat de consument maar moest aantonen dat zijn apparatuur op orde was. Het zou nooit aan de bank liggen.Geen steekhoudend en zelfs vals argument. Dat neemt namelijk niet weg dat voorkomen van een inbraak op de server van de bank en de detectie hiervan een verantwoordelijkheid is van de bank, en dat je dus mag verwachten dat daar voldoende aandacht aan wordt besteed. Zeker bij zulke grote banken als ING.
(mijn.ing.nl scoort bijvoorbeeld een A- in ssllabs. Een prima score. Geen ernstige zaken te bespeuren)
Verder wordt nergens beweerd dat het nooit aan de bank zou kunnen liggen. Dat dit niet in de veiligheidsregels staat,
heeft ermee te maken dat de veiligheidsregels zijn bedoeld voor klanten. Ze gaan over dingen waar de klant voor dient te zorgen. En de klant hoeft er nu eenmaal niet voor te zorgen dat de bank ook zelf zijn zaakjes op orde moet hebben.
(een hele andere kwestie is of de huidige interbankierregels voor klanten nou een schoonheidsprijs verdient.
Er valt wel wat op aan te merken)
****************************************************************************************************************************************
Dit probleem is simpel op te lossen door je wachtwoord regelmatig te wijzigen, bijv. elke drie maanden.
Aan het belang van periodiek veranderen van wachtwoorden wordt zo te zien door ING gelukkig al aandacht besteed,
hoewel het raadzaam zou zijn om zoiets voor iedereen verplicht te stellen, en op een goede manier te automatiseren.
(voor zover dit al niet gebeurt)
Niet eens: Dat is nu net de grap hier , Het veplichten van WW veranderen (onaangekondigd) in een transactie was het echte problem (vermoed ideal gebruik). Aangezien ww gedoe zo'n probleem is is lastpass ingezet (1 master ww en opgeslage). Deze symptoombestrijder voor ww gedoe gaf een probeem.
Doe eens een risicoanalyse: Het lijkt me het zwakke punt wat misbruikt kan worden door malware.
Dit punt bij transacties (ideal) oppakken en dan die verplichting simuleren. Als gebruiker niet eenvoudig te herkennen of het echt ING is of niet. Gebruiker staat onder druk van de transactie, wil snel door.
Een beetje meer social engineering en je kunt dat mogelijk ook wel met internetbankieren en de app zoiets doen.
Als je een risicoanalyse voorstelt, oordeel dan niet voordat die risicoanalyse grondig is gedaan.
Ik had met opzet neergeschreven:
Dat zal een gedegen risicoanalyse immers nog moeten uitwijzen. Blijkt het "niet goed", dan zal men de conditie moeten stellen "niet midden in een ideal transactie" als dat een beter alternatief zou zijn. Ook kun je enige coulance inbouwen
dat internetbankieren eerst een paar keer (bijv. tijdens normale inlogsessies) alleen maar een waarschuwing geeft dat het weer tijd wordt voor een nieuw wachtwoord, en tevens vraagt of de klant dit direct wil doen of later.
En pas als de termijn te ver is overschreden direct een nieuw wachtwoord eisen.
(je moet dacht ik sowieso volgens de bankregels minstens 1x in de twee weken je rekeningen controleren...)
********************************************************************************************************************************************
(dit is slechts één aspect van het internetbankieren van ING dat hier onder de loep is genomen,
en zegt niets over ING als geheel, en of de werkplekken van het personeel wel goed onderhouden worden, etc. etc...)
Niet eens. Als de cultuur er eentje is waar de security awareness ondermaats is, kun je ondermaats (risicovol gedrag) verwachten over de hele lijn. Dat wordt helaas gecombineerd met afschuiven van de verantwoordelijkheid, ontkennen etc.
.....
Niet eens, als je over misbruik risicoanalyse wil denken moet je ook die andere gevallen willen kunnen zien.
Suggereer en generaliseer je niet teveel? De uitslag van SSLLABS dan?... Die is niet ondermaats.
Kan natuurlijk altijd nóg een stukje beter, maar ondermaats? Nee. Dat gedeelte niet op dit moment.
In de meeste bedrijven heb je gedeeltes die prima in orde zijn en gedeeltes die te wensen overlaten.
De gedeeltes die te wensen overlaten moeten worden aangepakt.
Met mensen van een helpdesk idemdito: de één doet het beter en/of spant zich meer voor klanten in dan de ander.
(kan mede afhankelijk zijn van werkdruk, ergens een bepaalde "graaidruk", of persoonlijke omstandigheden, etc.)
En dat je andere gevallen in een risicoanalyse moet meenemen lijkt me vanzelfsprekend. kDacht niet dat ik je op dat punt ergens heb tegengesproken. (hooguit is mijn analyse anders dan de jouwe?)
******************************************************************************************************************************************
Iets anders:
Risicoanalyse is ook niet altijd even gemakkelijk.
Neem nu de ID scanner bij ING waar ik laatst iets over hoorde, om (zoals ze zeggen) je ID te controleren op echtheid.
En als je je zorgen maakt: "nee hoor meneer/mevrouw, we maken geen kopie,
kopieën maken we alleen bij het openen van een nieuwe rekening."
Aan de ene kant: een apparaat is niet te verslaan bij zulke controleprocessen, dus goed.
Aan de andere kant: dat is nog maar de vraag of er geen kopie wordt gemaakt!
Een klant kan dit toch niet controleren?
Voor je het weet zit ie toch in een lokale PC of server, die weer gehackt zou kunnen worden etc.
Wat denk je (denken jullie) daar van?
Goeroehoedjes van anoniem 16:38 (wordt al een hele stapel nu?...)
Door karma4:
Spijkers op laag water weer. (en wat heb je zelf nou gevraagd/geverifieerd bij T.S.?)Door Anoniem: Eerst even voor de goede orde:
Dit topic ging in de eerste plaats over het gemis van ondersteuning voor een aantal special karakters in wachtwoorden van
ING internetbankieren, en de hiermee samenhangende problemen .....:
Niet eens: De vraag die je daarbij moet stellen is die vraag wel het juiste probleem of .. gaat het om sypmtoombestrijding en is er wat anders. Een stukje probleemanalyse.Dit topic ging in de eerste plaats over het gemis van ondersteuning voor een aantal special karakters in wachtwoorden van
ING internetbankieren, en de hiermee samenhangende problemen .....:
Dan moet je bij bijna iedere TopicStarter tot aan vervelends toe elke keer eerst vragen "en wat bedoel je daar nou precies mee?" Dit is een forum. Als een TopicStarter ziet dat het de verkeerde kant uit gaat, blijft hij i.h.a. niet zwijgen.
Op basis van het topic van T.S én https://www.security.nl/posting/435037 dat klaarblijkelijk ook door TS is
geschreven, plus daarbij de stand van de discussie op dat moment en een stukje inlevingsvermogen, is wel te concluderen dat zoiets op dat moment aan de orde was. Dat kan niemand ontkennen.
Maar T.S. heeft inmiddels een nadere toelichting gegeven op wat hij in de kern precies bedoelde, waarvoor dank!
*********************************************************************************************************************************************
b) Voorkomen van inbraak en de detectie hiervan is eveneens een verantwoordelijkheid van de bank.
Je mag verwachten dat banken daar veel aandacht aan besteden, dus inbreken zal vast niet gemakkelijk gaan.
Wat nu als het tegendeel het geval is? Die onderbouwing is er wel:
Ze hadden met de NVB richtlijnen opgesteld voor de computer thuis (internet access) die zo uitgelegd konden worden dat de consument maar moest aantonen dat zijn apparatuur op orde was. Het zou nooit aan de bank liggen.
(mijn.ing.nl scoort bijvoorbeeld een A- in ssllabs. Een prima score. Geen ernstige zaken te bespeuren)
Verder wordt nergens beweerd dat het nooit aan de bank zou kunnen liggen. Dat dit niet in de veiligheidsregels staat,
heeft ermee te maken dat de veiligheidsregels zijn bedoeld voor klanten. Ze gaan over dingen waar de klant voor dient te zorgen. En de klant hoeft er nu eenmaal niet voor te zorgen dat de bank ook zelf zijn zaakjes op orde moet hebben.
(een hele andere kwestie is of de huidige interbankierregels voor klanten nou een schoonheidsprijs verdient.
Er valt wel wat op aan te merken)
****************************************************************************************************************************************
Dit probleem is simpel op te lossen door je wachtwoord regelmatig te wijzigen, bijv. elke drie maanden.
Aan het belang van periodiek veranderen van wachtwoorden wordt zo te zien door ING gelukkig al aandacht besteed,
hoewel het raadzaam zou zijn om zoiets voor iedereen verplicht te stellen, en op een goede manier te automatiseren.
(voor zover dit al niet gebeurt)
Doe eens een risicoanalyse: Het lijkt me het zwakke punt wat misbruikt kan worden door malware.
Dit punt bij transacties (ideal) oppakken en dan die verplichting simuleren. Als gebruiker niet eenvoudig te herkennen of het echt ING is of niet. Gebruiker staat onder druk van de transactie, wil snel door.
Een beetje meer social engineering en je kunt dat mogelijk ook wel met internetbankieren en de app zoiets doen.
Als je een risicoanalyse voorstelt, oordeel dan niet voordat die risicoanalyse grondig is gedaan.
Ik had met opzet neergeschreven:
...om zoiets voor iedereen verplicht te stellen, en op een goede manier te automatiseren.
Daarmee heb ik in het midden gelaten of een wachtwoordwijziging in een ideal transactie "goed" is of niet.Dat zal een gedegen risicoanalyse immers nog moeten uitwijzen. Blijkt het "niet goed", dan zal men de conditie moeten stellen "niet midden in een ideal transactie" als dat een beter alternatief zou zijn. Ook kun je enige coulance inbouwen
dat internetbankieren eerst een paar keer (bijv. tijdens normale inlogsessies) alleen maar een waarschuwing geeft dat het weer tijd wordt voor een nieuw wachtwoord, en tevens vraagt of de klant dit direct wil doen of later.
En pas als de termijn te ver is overschreden direct een nieuw wachtwoord eisen.
(je moet dacht ik sowieso volgens de bankregels minstens 1x in de twee weken je rekeningen controleren...)
********************************************************************************************************************************************
(dit is slechts één aspect van het internetbankieren van ING dat hier onder de loep is genomen,
en zegt niets over ING als geheel, en of de werkplekken van het personeel wel goed onderhouden worden, etc. etc...)
.....
Niet eens, als je over misbruik risicoanalyse wil denken moet je ook die andere gevallen willen kunnen zien.
Kan natuurlijk altijd nóg een stukje beter, maar ondermaats? Nee. Dat gedeelte niet op dit moment.
In de meeste bedrijven heb je gedeeltes die prima in orde zijn en gedeeltes die te wensen overlaten.
De gedeeltes die te wensen overlaten moeten worden aangepakt.
Met mensen van een helpdesk idemdito: de één doet het beter en/of spant zich meer voor klanten in dan de ander.
(kan mede afhankelijk zijn van werkdruk, ergens een bepaalde "graaidruk", of persoonlijke omstandigheden, etc.)
En dat je andere gevallen in een risicoanalyse moet meenemen lijkt me vanzelfsprekend. kDacht niet dat ik je op dat punt ergens heb tegengesproken. (hooguit is mijn analyse anders dan de jouwe?)
******************************************************************************************************************************************
Iets anders:
Risicoanalyse is ook niet altijd even gemakkelijk.
Neem nu de ID scanner bij ING waar ik laatst iets over hoorde, om (zoals ze zeggen) je ID te controleren op echtheid.
En als je je zorgen maakt: "nee hoor meneer/mevrouw, we maken geen kopie,
kopieën maken we alleen bij het openen van een nieuwe rekening."
Aan de ene kant: een apparaat is niet te verslaan bij zulke controleprocessen, dus goed.
Aan de andere kant: dat is nog maar de vraag of er geen kopie wordt gemaakt!
Een klant kan dit toch niet controleren?
Voor je het weet zit ie toch in een lokale PC of server, die weer gehackt zou kunnen worden etc.
Wat denk je (denken jullie) daar van?
Goeroehoedjes van anoniem 16:38 (wordt al een hele stapel nu?...)
13-07-2015, 20:50 door
karma4
Door Anoniem: 17:17
om te beginnen je hq (humorquotient) mag wat bijgesteld worden. Spijkers op laag water weer. (en wat heb je zelf nou gevraagd/geverifieerd bij T.S.?
Hij heeft zich gemeld en de popup als onderbreking is bevestigd. Het stond in een combinatie van zijn posts. Ik heb ooit zelf ook de problematiek gehad. Het lastige onberekenbare breikbaar zijn heeft als klacht via webwinkels de kranten gehaald.Toch mooi dat we niet allemaal het zelfde zijn en er afwijkende ideeen zijn? Anders zou het wel heel saai worden.
NVB Geen steekhoudend en zelfs vals argument. ---
(een hele andere kwestie is of de huidige interbankierregels voor klanten nou een schoonheidsprijs verdient.
Er valt wel wat op aan te merken)
Het heeft allemaal opgespeeld, Er zijn andere posts discussies voor. We verschillen duidelijk van mening. Het is geen vals argument als je met wat zaken van doen heb gehad (archief consumentenbond - posts dwang om ouderen te laten internetbankieren). Nu weet ik ook nog een beetje hoe er daar intern gewerkt wordt. We kunnen het bij het meningsverschil laten, het hoort niet meer in deze thread. (een hele andere kwestie is of de huidige interbankierregels voor klanten nou een schoonheidsprijs verdient.
Er valt wel wat op aan te merken)
(mijn.ing.nl scoort bijvoorbeeld een A- in ssllabs. Een prima score. Geen ernstige zaken te bespeuren.
Effe checken en http://www.automatiseringgids.nl/nieuws/2015/08/ing-lek-als-een-zeef-in-belgie het is het beeld van eerdere berichten pas nadat het in de publiciteit komt, wordt er actie ondernomen. Let wel dat gaat enkel over het SSL deel niet de gehele functionaliteit.Als je een risicoanalyse voorstelt, oordeel dan niet voordat die risicoanalyse grondig is gedaan.
Jij stelde hem voor, ik nam een voorschot. Anderen kunnen er geheel open over meedenken. Dat ING zelf zoiets intern moet doen is goed, maar zichzelf keuren dat ze het goed of fout doen en dat die de enige waarheid is... Bedoel je dat serieus of als grap?
je moet dacht ik sowieso volgens de bankregels minstens 1x in de twee weken je rekeningen controleren..
Als je het over storneren en niet afgegeven incassomachtingen hebt kijk het dan even na http://www.incassomachtigen.nl/consument/incasso-terugboeken-storneren/ De perioden zijn veel langer. Daarmee komt er meer risico bij de banken te liggen. Vinden ze niet leuk. Incassofraude komt voor. ******************************************************************************************************************************************
......
Voor je het weet zit ie toch in een lokale PC of server, die weer gehackt zou kunnen worden etc.
Wat denk je (denken jullie) daar van?
Goeroehoedjes van anoniem 16:38 (wordt al een hele stapel nu?...)
Voor je het weet zit ie toch in een lokale PC of server, die weer gehackt zou kunnen worden etc.
Wat denk je (denken jullie) daar van?
Goeroehoedjes van anoniem 16:38 (wordt al een hele stapel nu?...)
Wat denk je dat er met alle data gebeurd die onder de noemer van big-data verzameld worden voor marketing doeleinden. Zoiets waardevols bewaar je toch. Anderzijds heb ik zelf ervaren (meerdere malen) dat ze de benodigde registraties voor bepaalde rekeningen gewoon kwijt waren en opnieuw begonnen te vragen.
Die marketing speeltjes zijn vaker de onbedoelde lekken geweest. Een "tijdelijke"machine die dan vergeten wordt.
De opmerking dat het op een lokale PC/Server komt die gehackt kan worden. Kijk daar zijn we het weer eens.
Wat dacht je van eigen/vraag topic hierover?
Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
"vermoeden" zonder het schaamrood op je kaken gebruiken op een security pagina? Ga je mond spoelen.
Verder heb je inderdaad geen idee. (maar dat idee hadden de meeste mensen hier al denk ik)
Om te beginnen bedankt voor je reactie Karma4!
Geen dingen meer zeggen waar ik bijna van moet huilen hoor. ;-)
Maar laten we niet te pessimistisch wezen: over een aantal dingen zijn we het aardig eens.
Over andere dingen misschien niet. En soms begrijpen we elkaar misschien niet helemaal. Kan beure. Mag best.
Dat ING zelf zoiets intern moet doen is goed, maar zichzelf keuren dat ze het goed of fout doen en dat die de enige waarheid is... Bedoel je dat serieus of als grap?Heb het er niet over gehad wie die risicoanalyse dan moet gaan doen hoor. kprobeerde het daarna zelf al een beetje.
En ja, min of meer ook als grapje bedoeld omdat je jezelf met dat haastige "niet eens met verplichte wachtwoorden"
in je argumentatie nogal fixeerde op dat ideal-geval, waarmee je jezelf een tikkie "vulnerable" maakte. ;=)
Die "niet mee eens" argumentatie van jou was namelijk gemakkelijk onderuit te halen, omdat verplichte wachtwoorden
ook wel zó kunnen worden geïmplementeerd dat je er niet tijdens idealsessies mee wordt lastiggevallen.
En verder vond ik dat een gedegen risicoanalyse maar moet uitwijzen hoe je verplicht w.w. wijzigen het beste kan doen.
Die twee minuten dat jij en ik er op afstand mee bezig zijn kan je geen gedegen risicoanalyse noemen vind ik.
Dus "risicoanalyse" bedoelde ik in dat quoted zinnetje hierboven wat dubbelzinnig: deels grapje én deels serieus
Tja, Belgen... Mijnheer Tiete had op 20 januari 2015 gelukkig ontdekt dat het gros van de Belgische banken niet op orde was met hun SSL. En laat de Belgische ING nou ook nog in de onderste regionen zitten: grade F
Oeijoeijoeijoeijoeijoeijoei... Nog altijd SSL3 enabled (= de oorzaak van grade "F"...; ging op 8 dec.2014 van "B" naar "F")
Waarschijnlijke hoofdoorzaak: bank probeerde nog wat langer compatible te blijven met oude systemen als XP.
(anders loopt misschien de helpdesk in no time roodgloeiend "waarom doet mijn internetbankieren het niet meer pj3?!"
En als je een boze Belg op je dak krijgt, nou berg je dan maar! Die stapt zo naar een andere bank, maakt niet uit of de bank gelijk heeft of niet. Cultuurverschilletje.
Anyhow, kennelijk zijn een aantal Belgische banken in verleiding gekomen, waaronder de Belgische ING.
Maar zoals je ziet scoorde de Nederlandse tak van ING in oktober 2014 (dit was dus al ca. drie maanden eerder...)
bijna de hoogste score, en was het poodle-lek en SSL3 bij ING Nederland al netjes gedicht:
https://www.security.nl/posting/406070/Veilig+internetbankieren%3A+huidige+status+bankservers
En ze waren na het nieuw TLS POODLE lek (één van?) de eerste(n) die het lek fixten. Andere grote banken een dag later.
Zie commentaar onder https://www.security.nl/posting/411274/Nieuwe+POODLE-aanval+tegen+TLS+raakt+10%25+van+de+servers
Het kan verkeren. Nou jij weer. Zoals ik dus in een eerder bericht ook al zei:
Maar kan geen kwaad om de boel vanaf hier een beetje in de gaten houden natuurlijk. ;-)
Laat ik tot slot nog even melden dat ik met dat "één keer in de veertien dagen de rekening controleren" bedoelde: https://www.ing.nl/de-ing/veilig-bankieren/5Bs-van-veilig-bankieren/bekijk-uw-afschrijvingen/
Goeroehoedjes! (voor als je nog hoedjes tekort komt)
om te beginnen je hq (humorquotient) mag wat bijgesteld worden.
Graag! Help eens ff met bijstellen?Geen dingen meer zeggen waar ik bijna van moet huilen hoor. ;-)
Maar laten we niet te pessimistisch wezen: over een aantal dingen zijn we het aardig eens.
Over andere dingen misschien niet. En soms begrijpen we elkaar misschien niet helemaal. Kan beure. Mag best.
Als je een risicoanalyse voorstelt, oordeel dan niet voordat die risicoanalyse grondig is gedaan.
Jij stelde hem voor, ik nam een voorschot. Anderen kunnen er geheel open over meedenken.Dat ING zelf zoiets intern moet doen is goed, maar zichzelf keuren dat ze het goed of fout doen en dat die de enige waarheid is... Bedoel je dat serieus of als grap?
En ja, min of meer ook als grapje bedoeld omdat je jezelf met dat haastige "niet eens met verplichte wachtwoorden"
in je argumentatie nogal fixeerde op dat ideal-geval, waarmee je jezelf een tikkie "vulnerable" maakte. ;=)
Die "niet mee eens" argumentatie van jou was namelijk gemakkelijk onderuit te halen, omdat verplichte wachtwoorden
ook wel zó kunnen worden geïmplementeerd dat je er niet tijdens idealsessies mee wordt lastiggevallen.
En verder vond ik dat een gedegen risicoanalyse maar moet uitwijzen hoe je verplicht w.w. wijzigen het beste kan doen.
Die twee minuten dat jij en ik er op afstand mee bezig zijn kan je geen gedegen risicoanalyse noemen vind ik.
Dus "risicoanalyse" bedoelde ik in dat quoted zinnetje hierboven wat dubbelzinnig: deels grapje én deels serieus
Tja, Belgen... Mijnheer Tiete had op 20 januari 2015 gelukkig ontdekt dat het gros van de Belgische banken niet op orde was met hun SSL. En laat de Belgische ING nou ook nog in de onderste regionen zitten: grade F
Oeijoeijoeijoeijoeijoeijoei... Nog altijd SSL3 enabled (= de oorzaak van grade "F"...; ging op 8 dec.2014 van "B" naar "F")
Waarschijnlijke hoofdoorzaak: bank probeerde nog wat langer compatible te blijven met oude systemen als XP.
(anders loopt misschien de helpdesk in no time roodgloeiend "waarom doet mijn internetbankieren het niet meer pj3?!"
En als je een boze Belg op je dak krijgt, nou berg je dan maar! Die stapt zo naar een andere bank, maakt niet uit of de bank gelijk heeft of niet. Cultuurverschilletje.
Anyhow, kennelijk zijn een aantal Belgische banken in verleiding gekomen, waaronder de Belgische ING.
Maar zoals je ziet scoorde de Nederlandse tak van ING in oktober 2014 (dit was dus al ca. drie maanden eerder...)
bijna de hoogste score, en was het poodle-lek en SSL3 bij ING Nederland al netjes gedicht:
https://www.security.nl/posting/406070/Veilig+internetbankieren%3A+huidige+status+bankservers
En ze waren na het nieuw TLS POODLE lek (één van?) de eerste(n) die het lek fixten. Andere grote banken een dag later.
Zie commentaar onder https://www.security.nl/posting/411274/Nieuwe+POODLE-aanval+tegen+TLS+raakt+10%25+van+de+servers
Het kan verkeren. Nou jij weer. Zoals ik dus in een eerder bericht ook al zei:
In de meeste bedrijven heb je gedeeltes die prima in orde zijn en gedeeltes die te wensen overlaten.
De gedeeltes die te wensen overlaten moeten worden aangepakt.
De gedeeltes die te wensen overlaten moeten worden aangepakt.
Maar kan geen kwaad om de boel vanaf hier een beetje in de gaten houden natuurlijk. ;-)
Laat ik tot slot nog even melden dat ik met dat "één keer in de veertien dagen de rekening controleren" bedoelde: https://www.ing.nl/de-ing/veilig-bankieren/5Bs-van-veilig-bankieren/bekijk-uw-afschrijvingen/
Goeroehoedjes! (voor als je nog hoedjes tekort komt)
15-07-2015, 22:55 door
karma4
@Goeroehoedjes!
Kijk maar eens naar "ïk zie het nu pas" Dat was na een paar nachtjes slapen.
Een beetje bekend met de interne organisatie kan ik je op een briefje geven dat alles volgens afvinklijstjes gaat. Daar hoef ik geen hoedje voor op te zetten al zou je er een hoedje van kunnen schrikken. Het is dogmatisch process gericht werken organisatie met vele bokitootjes. En kosten is helaas zaligmakend naast de eigen persoonlijke inkomsten.
Maar laten we niet te pessimistisch wezen: over een aantal dingen zijn we het aardig eens. eens
Die twee minuten dat jij en ik er op afstand mee bezig zijn kan je geen gedegen risicoanalyse noemen vind ik.
Nee het waren echt geen 2 minuutjes. Zoals genoemd ook een paar (wat een paar - best veel) eerdere ervaringen. Het maakt je attenter op de zelfde soort situaties. Nog steeds lastig te herkennen. Kijk maar eens naar "ïk zie het nu pas" Dat was na een paar nachtjes slapen.
Een beetje bekend met de interne organisatie kan ik je op een briefje geven dat alles volgens afvinklijstjes gaat. Daar hoef ik geen hoedje voor op te zetten al zou je er een hoedje van kunnen schrikken. Het is dogmatisch process gericht werken organisatie met vele bokitootjes. En kosten is helaas zaligmakend naast de eigen persoonlijke inkomsten.
En laat de Belgische ING nou ook nog in de onderste regionen zitten: grade F
In je link stond ING ook open en pas na publicatie snel aangepast. Verbaast me wel dat het bij de belgen niet is gebeurt. Ze delen het datacenter en de meeste aanpak van alles. Meestal zijn de Belgen (wat kleiner) het voorportaal wat er Nederland gebeurt. De huidige ING-bank inrichting voor klanten kon je daar het eerst zien. Je zou het echt als de proeftuin kunnen zien. R Hamers is daar "opgeleid". Geheim maar niet geheel geheim is http://www.bndestem.nl/regio/roosendaal/datacenter-colt-naar-roosendaal-1.233191 - http://www.datacenterdynamics.com/news/from-crisis-to-cloud-ings-data-center-strategy/69839.fullarticle De genoemde locatie is logischer als het 1 geheel is. Wat zou kunnen is dat men toch wat alerter reageert in NL na dat DDOS debacle. Maar laten we niet te pessimistisch wezen: over een aantal dingen zijn we het aardig eens. eens
Ik moest net ook mijn wachtwoord veranderen. Ik ben het geheel eens met de strekking van de vragen/opmerkingen van Anoniem 08-07-2015, 18:56 .
Ik vind het belachelijk dat ING in deze tijd nog restricties toepast op het gebruik van speciale tekens: verbied ze of sta ze allemaal toe! Nu moest ik speciaal teken voor teken (20) controleren of dat van de ING mag. Dat
- introduceert fouten,
- het is gebruiksonvriendelijk en
- het introduceert zwakke wachtwoorden: velen zullen geneigd zijn geen random tekens (lijkend op het vorige wachtwoord) te kiezen.
(Ik zwijg maar niet over de maximale lengte ivm wachtzinnen, ING wanneer gaat dat naar 50 of zoiets?)
Ik vind het belachelijk dat ING in deze tijd nog restricties toepast op het gebruik van speciale tekens: verbied ze of sta ze allemaal toe! Nu moest ik speciaal teken voor teken (20) controleren of dat van de ING mag. Dat
- introduceert fouten,
- het is gebruiksonvriendelijk en
- het introduceert zwakke wachtwoorden: velen zullen geneigd zijn geen random tekens (lijkend op het vorige wachtwoord) te kiezen.
(Ik zwijg maar niet over de maximale lengte ivm wachtzinnen, ING wanneer gaat dat naar 50 of zoiets?)
Door Anoniem: >Het wachtwoord is minimaal 8 en maximaal 20 karakters lang
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
>Overige tekens: @, #, $ en %
Doet mij sterk vermoeden dat zij de wachtwoorden niet hashen en dus plain opslaan.
Deze regels kunnen namelijk compleet weg als je wachtwoorden hashed/encrypted in de db bewaard.
Dit hoeft niet waar te zijn, al ben ik het met je eens dat het geen enkel probleem moet zijn om wachtwoorden van elke lengte op te slaan.
Je ziet wel vaker dat er bewust voor een maximale lengte wordt gekozen. Als argument hiervoor heb ik wel eens gehoord dat ze op deze manier willen voorkomen dat gebruikers een te lang wachtwoord maken dat ze niet meer kunnen onthouden. Of dat waar is durf ik niet te zeggen maar ik kan me er wel iets bij voorstellen.
Overigens lijkt het me erg onwaarschijnlijk dat de ING niet aan password-hashing doet. Dit staat namelijk als verplicht in de landelijke code bescherming persoonsgegevens. Als zij zich hier niet aan houden hebben ze een enorm probleem. Om die reden denk ik dat ze de kleine moeite wel kunnen nemen hun wachtwoorden te hashen.
hahaha mooi antwoord. kreeg je het antwoord toevallig van ING@sffjskjffskjfsv.co.nz terug?
....Als argument hiervoor heb ik wel eens gehoord dat ze op deze manier willen voorkomen dat gebruikers een te lang wachtwoord maken dat ze niet meer kunnen onthouden....
Wie gaat er nu z'n wachtwoorden onthouden?
Dat lukt alleen met eenvoudige korte wachtwoorden.
Nee, gewoon sterke wachtwoorden bedenken, en uitprinten zodat je ze kunt intypen wanneer nodig.
Hoi Karma4,
Hieronder nog even een iets verlate reactie op jouw https://www.security.nl/posting/435783
Een risicoanalyse? Jazeker.
Maar een gedegen risicoanalyse? Nee. Die zou volgens mij veel verder moeten gaan.
Is nog geen gedegen risicoanalyse op het specifieke probleem dat hier aan de orde is. (pwd change tijdens ideal sessie)
Maar... is volgens mij nog steeds geen gedegen risicoanalyse. Wij kijken imho nog teveel van een afstand.
En wat bedoel je eigenlijk met pop-up? Ik versta daar een nieuw windootje onder. Bijv. als je gaat inloggen
in de meeste routers. Ben met je eens dat wanneer er op soortgelijke wijze een nieuw windootje "oppopt"
bij ING internetbankieren met een verzoek voor een nieuw wachtwoord dat dit dan risicovol is.
Maar wat ik me dus afvraag is: gebeurt die pwd change eigenlijk wel d.m.v. zo'n pop-up? Wie zegt dat?
Misschien is het wel zo dat ING in de "main window" om een nieuw pwd vraagt. Zonder nieuw popup window dus.
In dat geval zijn de risico's imho alweer een heel stuk minder.
Maar neemt nog niet weg dat zoiets midden in een ideal transactie niet bepaald ideaal is... "Een beetje koddig".
Het leidt wat af terwijl je midden in een transactie zit. En dat is geen ideaal recept voor maximale security.
Dat ben ik wel met je eens. Of het desondanks acceptabel is, is een andere kwestie. Het zou bijv. acceptabel kunnen zijn
als de klant al meerdere kwartalen hetzelfde wachtwoord blijft gebruiken en andere change requests aan zijn laars lapt.
Voor een echt gedegen risico-analyse zou je misschien zelfs over de programmacode moeten beschikken.
Maar dat kunnen wij niet: wij beschikken niet over de programmacode. Daarom kunnen jij en ik nog maar een beperkte risicoanalyse maken. En hierop kun je imho maar beter niet teveel je oordeel stellen vind ik.
(als je tenminste zoveel mogelijk streeft naar rechtvaardige oordelen)
Over afvinklijstjes: afvinklijstjes hebben ook voordelen: je vergeet bepaalde dingen niet, je treedt uniform naar buiten toe.
Nadelen: gezond verstand is soms onvindbaar, en het kan erg "machinaal" (onmenselijk) overkomen.
Verder nog als voordeel voor de bank: je hebt niet al te dure mensen nodig. ("kind kan de was doen")
En om me heen zie ik best veel volwassenen die zich gedragen als kinderen. Past goed bij elkaar dus?...
Echter dan wel pech voor een minderheid die moeite heeft genomen om wat meer verstand op te bouwen. ;-)
Bijv. als niet alleen in theorie, maar ook in de praktijk over de jaren heen al zou zijn gebleken
dat het huidige wachtwoordbeleid niet leidt tot een spontaan frauduleus inloggen van onbevoegden,
of tot onoverkoombare ongemakken, of tot een (niet correct gegrond) onveiligheidsgevoel bij veel klanten,
waarom zou je dan geld verspillen om het te veranderen of uit te breiden?
Met gebruikmaken van hun 2-factor per SMS er nog bij lijkt het me meer dan veilig, tenminste
voor wat betreft het inloggen en de transacties dan. (verder weet ik het niet precies: mocht de commercie hun internetbankierapplicatie infitreren, dan kan het hard achteruitgaan met de privacy en dus veiligheid van de klant,
en heb je niets aan zelfs ook de allerveiligste inlogmethoden...)
En o ja: Forward Secrecy toevoegen om de puntjes op de i te zetten?
Vind je het gek dat ING open stond:
pas op 8-12 werd dit lek voor het eerst bekendgemaakt, op 9-12 stond het op security.nl.
Mag een bank dan alsjeblieft één of twee dagen om fix voor te bereiden en op een geschikt moment te implementeren?
Het is zo snel gegaan dat je niet kunt bewijzen waar ING nu precies op heeft gereageerd. (niet alles is wat het lijkt)
Dit staat niet in verhouding tot de Belgische ING, die nadat zij werden gemaand door mijnheer Tiete
dat advies nog zowat een maand lang lijkt te hebben genegeerd.
(zo zie je maar weer: Al het goeie komt van...????... Nou ja, volgens Peer dan he) ;-)
Voor de rest ben ik het voor het grootste deel wel met je eens Karma4. Thanx! :-)
Goeroehoedjes weer (en gooi maar in de prullebak als je ze niet nodig hebt)
Hieronder nog even een iets verlate reactie op jouw https://www.security.nl/posting/435783
Nee het waren echt geen 2 minuutjes.
Was bedoeld bij wijze van spreken uiteraard. Een risicoanalyse? Jazeker.
Maar een gedegen risicoanalyse? Nee. Die zou volgens mij veel verder moeten gaan.
Zoals genoemd ook een paar (wat een paar - best veel) eerdere ervaringen. Het maakt je attenter op de zelfde soort situaties. Nog steeds lastig te herkennen.
Je preekt over jouw algemene ervaring met risico's. ;-)Is nog geen gedegen risicoanalyse op het specifieke probleem dat hier aan de orde is. (pwd change tijdens ideal sessie)
Kijk maar eens naar "ïk zie het nu pas" Dat was na een paar nachtjes slapen.....
Hee ik zie het nu pas dat je hier twee puntjes op de "ï" hebt?... ;-)Maar... is volgens mij nog steeds geen gedegen risicoanalyse. Wij kijken imho nog teveel van een afstand.
En wat bedoel je eigenlijk met pop-up? Ik versta daar een nieuw windootje onder. Bijv. als je gaat inloggen
in de meeste routers. Ben met je eens dat wanneer er op soortgelijke wijze een nieuw windootje "oppopt"
bij ING internetbankieren met een verzoek voor een nieuw wachtwoord dat dit dan risicovol is.
Maar wat ik me dus afvraag is: gebeurt die pwd change eigenlijk wel d.m.v. zo'n pop-up? Wie zegt dat?
Misschien is het wel zo dat ING in de "main window" om een nieuw pwd vraagt. Zonder nieuw popup window dus.
In dat geval zijn de risico's imho alweer een heel stuk minder.
Maar neemt nog niet weg dat zoiets midden in een ideal transactie niet bepaald ideaal is... "Een beetje koddig".
Het leidt wat af terwijl je midden in een transactie zit. En dat is geen ideaal recept voor maximale security.
Dat ben ik wel met je eens. Of het desondanks acceptabel is, is een andere kwestie. Het zou bijv. acceptabel kunnen zijn
als de klant al meerdere kwartalen hetzelfde wachtwoord blijft gebruiken en andere change requests aan zijn laars lapt.
Voor een echt gedegen risico-analyse zou je misschien zelfs over de programmacode moeten beschikken.
Maar dat kunnen wij niet: wij beschikken niet over de programmacode. Daarom kunnen jij en ik nog maar een beperkte risicoanalyse maken. En hierop kun je imho maar beter niet teveel je oordeel stellen vind ik.
(als je tenminste zoveel mogelijk streeft naar rechtvaardige oordelen)
Over afvinklijstjes: afvinklijstjes hebben ook voordelen: je vergeet bepaalde dingen niet, je treedt uniform naar buiten toe.
Nadelen: gezond verstand is soms onvindbaar, en het kan erg "machinaal" (onmenselijk) overkomen.
Verder nog als voordeel voor de bank: je hebt niet al te dure mensen nodig. ("kind kan de was doen")
En om me heen zie ik best veel volwassenen die zich gedragen als kinderen. Past goed bij elkaar dus?...
Echter dan wel pech voor een minderheid die moeite heeft genomen om wat meer verstand op te bouwen. ;-)
En kosten is helaas zaligmakend naast de eigen persoonlijke inkomsten.
Bijna eens. Waarschijnlijk niet puur kosten. Maar: "kosten baten analyse".Bijv. als niet alleen in theorie, maar ook in de praktijk over de jaren heen al zou zijn gebleken
dat het huidige wachtwoordbeleid niet leidt tot een spontaan frauduleus inloggen van onbevoegden,
of tot onoverkoombare ongemakken, of tot een (niet correct gegrond) onveiligheidsgevoel bij veel klanten,
waarom zou je dan geld verspillen om het te veranderen of uit te breiden?
Met gebruikmaken van hun 2-factor per SMS er nog bij lijkt het me meer dan veilig, tenminste
voor wat betreft het inloggen en de transacties dan. (verder weet ik het niet precies: mocht de commercie hun internetbankierapplicatie infitreren, dan kan het hard achteruitgaan met de privacy en dus veiligheid van de klant,
en heb je niets aan zelfs ook de allerveiligste inlogmethoden...)
En o ja: Forward Secrecy toevoegen om de puntjes op de i te zetten?
In je link stond ING ook open en pas na publicatie snel aangepast.
Ja zeg, hallo Karma4, ik denk dat je dit toch echt te haastig hebt beoordeeld hoor. Vind je het gek dat ING open stond:
pas op 8-12 werd dit lek voor het eerst bekendgemaakt, op 9-12 stond het op security.nl.
Mag een bank dan alsjeblieft één of twee dagen om fix voor te bereiden en op een geschikt moment te implementeren?
Het is zo snel gegaan dat je niet kunt bewijzen waar ING nu precies op heeft gereageerd. (niet alles is wat het lijkt)
Dit staat niet in verhouding tot de Belgische ING, die nadat zij werden gemaand door mijnheer Tiete
dat advies nog zowat een maand lang lijkt te hebben genegeerd.
(zo zie je maar weer: Al het goeie komt van...????... Nou ja, volgens Peer dan he) ;-)
Voor de rest ben ik het voor het grootste deel wel met je eens Karma4. Thanx! :-)
Goeroehoedjes weer (en gooi maar in de prullebak als je ze niet nodig hebt)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
