Debian openssl-bug

[axis]

Voor de mensen die de afgelopen 24 uur onder een steen hebben geleefd:

Kreeg net na de melding op slashdot nog een mail van een van mijn favoriete podcasts, dat men nu bezig is rainbow tables te maken voor de openssh bug in debian en ubuntu

Newsflash at 4pm on Wednesday May 14. This is a Risky Business special
broadcast -- we have broken our regular programming schedule to bring you
this special report. Download it from:

http://itradio.com.au/security/

Most listeners would be aware that a serious bug in Debian's random number
generator has been patched overnight. Unfortunately, all keys generated by
Debian systems (and by the looks of things Ubuntu systems as well) are
completely useless and need to be regenerated.

That means you SSH and SSL content encryption AND authentication has been
rendered ineffective. Not only are your server generated keypairs
ineffective, any user-generated keypair made with a Debian or Ubuntu box
and accepted by an SSH server is vulnerable.

H D Moore is currently working on what sounds like a rainbow table-style
attack which will allow him to brute force authentication over SSH in 2.5
to 6 hours. Because of the rainbow table nature of the attack, it also
means he can decode intercepted packets in a matter of seconds.

Risky Business spoke to H D Moore via a VoIP line to his mobile phone in
Texas, where he's pulling a late night working on this...

Dat wordt dus snel patchen als je gevoelige systemen aan het net hebt hangen..

[TrailBlazer]

Hoe makkelijk denk je dat het is om die pakketten te intercepten. Als iemand tot dat in staat is betekent dat hij of een packetsniffer naast je server heeft staan of controle heeft over je ISP.

Die keypairs is wel wat vervelend.

[ Voor 8% gewijzigd door TrailBlazer op 14-05-2008 08:38 ]

[Arnout]

Patchen? Er is al een nieuwe versie van het openssl pakket gemaakt (0.9.8c-4etch3).

apt-get install openssl

Bedankt voor de melding.

[ Voor 10% gewijzigd door Arnout op 14-05-2008 08:44 ]

[TrailBlazer]

ja maar die patch maakt geen nieuwe key-pairs voor je dus die moet je we even gaan vervangen op al je systemen.

[axis]

Als ik het goed begrijp moet je daarvoor het volgende uitvoeren?

SSH1 protocol
For SSH1 protocol, you need a rsa1 key generated has follow:

code:

ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1

SSH2 protocol
For SSH2 protocol, you need two keys, one rsa key and one dsa key generated has follow:

code:

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

Heb alleen BSD bakken, dus kan het niet zo makkelijk testen

[Rukapul]

Is er ergens technischere informatie over de bug te vinden? Dan doel ik met name op het verlies van randomness (entropie) veroorzaakt door de bug.

[Creepy]

Op http://wiki.debian.org/SSLkeys staat een uitgebreide uitleg. Zie bijv ook. http://blog.zakame.net/news/openssl-remote-dsa-1571

Sarge niet vulnerable. Etch en hoger wel. SSL upgraden en voor alles die een key gebruikt die opnieuw genereren. Op http://wiki.debian.org/SSLkeys staat een uitgebreide checklist van welke apps zwakke keys kunnen hebben.

[ Voor 46% gewijzigd door Creepy op 14-05-2008 15:15 ]

[Seth4Chaos]

axis schreef op woensdag 14 mei 2008 @ 09:26:
Als ik het goed begrijp moet je daarvoor het volgende uitvoeren?

SSH1 protocol
For SSH1 protocol, you need a rsa1 key generated has follow:

code:

ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1

SSH2 protocol
For SSH2 protocol, you need two keys, one rsa key and one dsa key generated has follow:

code:

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

Heb alleen BSD bakken, dus kan het niet zo makkelijk testen

volgens mij kan je ook hetvolgende doen:
[code]rm /etc/ssh/ssh_host*
/etc/init.d/ssh restart[/code]
dan worden ze vanzelf opnieuw aangemaakt.

[ Voor 0% gewijzigd door Seth4Chaos op 14-05-2008 13:19 . Reden: rare praat... ]

[Zwerver]

Seth4Chaos schreef op woensdag 14 mei 2008 @ 09:57:
[...]


volgens mij kan je ook hetvolgende doen:

code:

rm /etc/ssh/ssh_host*
/etc/init.d/ssh restart

dan worden ze vanzelf opnieuw aangemaakt.

Nou nee hoor

da:~# rm /etc/ssh/ssh_host*
da:~# /etc/init.d/ssh restart
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Restarting OpenBSD Secure Shell server: sshdCould not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
.
da:~# 

Gelukkig niet zo'n probleem aangezien dat een xen guest is

[Pim.]

axis schreef op woensdag 14 mei 2008 @ 09:26:
Als ik het goed begrijp moet je daarvoor het volgende uitvoeren?

SSH1 protocol
For SSH1 protocol, you need a rsa1 key generated has follow:

code:

ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1

SSH2 protocol
For SSH2 protocol, you need two keys, one rsa key and one dsa key generated has follow:

code:

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

Heb alleen BSD bakken, dus kan het niet zo makkelijk testen

Werkt prima, alleen niet vergeten ssh te restarten

[phobosdeimos]

1) het gaat om een bug in de OpenSSL RNG, het is dus geen OpenSSH bug
2) het gaat enkel om Debian, want de bug is afkomstig van een Debian patch (dankzij erg slordige/ondoorzichtige/zonder commentaar code van het openssl team)
3) door de security fix te downloaden (apt-get) worden je hostkeys automatisch opnieuw aangemaakt
4) achteraf kan je je systeem checken met het nieuwe "ssh-vulnkey" commando

[Maasluip]

Rukapul schreef op woensdag 14 mei 2008 @ 09:42:
Is er ergens technischere informatie over de bug te vinden? Dan doel ik met name op het verlies van randomness (entropie) veroorzaakt door de bug.

Op /. wordt gesproken dat de seeding van de random number generator was verwijderd.

[phobosdeimos]

Maasluip schreef op woensdag 14 mei 2008 @ 10:20:
[...]

Op /. wordt gesproken dat de seeding van de random number generator was verwijderd.

De code van openssl gebruikte ergens een stukje "uninitialized memory" in de seed voor hun RNG. Dit wordt gespot door valgrind als een bug, en is door de brave package maintainers van Debian dan ook gefixt als zijnde een bug. Maar hierdoor hebben ze het hele seed mechanisme eigenlijk (onbewust) omzeep geholpen, waardoor de seed voor de openssl RNG in debian al 2 jaar dezelfde waarde is. Met als gevolg dat alle keys aangemaakt tussen toen en nu, perfect voorspelbaar zijn.

[Arnout]

Goed, wat is het risico voor een gemiddelde debian server die aan het internet hangt met SSH toegang? Ik heb 2 systemen op verschillende lokaties die elk uur via SSH rsyncen (rsnapshot) met behulp van een key-pair, moet ik z.s.m. nieuwe key's gaan maken of loopt het wel los?

[Creepy]

Anders lees je even de pagina's die ik link? Oftewel: op http://wiki.debian.org/SSLkeys staat alles uitgelegd.

De encryptie is in principe waardeloos, evenals je certificaten. Encypted verkeer is simpel te sniffen en dus ook wachtwoorden die over die encrypted verbinding gaan zijn dus simpel te achterhalen. Updaten dus van al die keys..

[ Voor 10% gewijzigd door Creepy op 14-05-2008 11:01 ]

[phobosdeimos]

@Arnout: er is een lijst beschikbaar, in package openssh-blacklist, met alle tainted keys. Jouw key zit daar ook tussen. En gezien jij de key gebruikt voor automatisch rsync neem ik aan dat je stiekem geen passphrase gebruikt. Dus al wat een aanvaller hoeft te doen is die blacklist aflopen tot hij jouw key te pakken heeft, kan hij mooi binnenwandelen. Zo snel mogelijk je keys vervangen & apt-get upgrade dus.

[eamelink]

Hmm, volgens is mijn meestgebruikte keypair een jaar of vier oud dus die moeten goed zijn, maar zal eens even nakijken

[edit]
Maar waarschijnlijk wel gebruikt op onveilige machines. Dan maar een nieuw setje maken.

[ Voor 29% gewijzigd door eamelink op 14-05-2008 11:12 ]

[eghie]

Misschien een interessant artikel ter opvolging van dit: Sterke toename SSH brute-force aanvallen

[Rukapul]

eamelink schreef op woensdag 14 mei 2008 @ 11:07:
[edit]
Maar waarschijnlijk wel gebruikt op onveilige machines. Dan maar een nieuw setje maken.

Gebruikt als in SSH remote login? Even afgezien van de cryptografische operaties waarin bij een authenticatie randomness wordt gebruikt die vervolgens tot het achterhalen van de private key kan leiden, vereist dit het sniffen en bewaren van authenticatiesessie verkeer in het verleden. Je kunt je afvragen hoe groot dat risico is. Waarschijnlijk relatief klein vergeleken met zwakke keys per se.

[phobosdeimos]

Af en toe een nieuwe key aanmaken is zowiezo geen slecht idee.
Plus altijd een (sterke) passphrase gebruiken (tenzij het niet anders kan bij automatisering).

[eamelink]

Rukapul schreef op woensdag 14 mei 2008 @ 12:04:
[...]

Gebruikt als in SSH remote login? Even afgezien van de cryptografische operaties waarin bij een authenticatie randomness wordt gebruikt die vervolgens tot het achterhalen van de private key kan leiden, vereist dit het sniffen en bewaren van authenticatiesessie verkeer in het verleden. Je kunt je afvragen hoe groot dat risico is. Waarschijnlijk relatief klein vergeleken met zwakke keys per se.

Klopt

Om die reden keys vervangen is inderdaad wat overbodig, maar het bleek dat ik toch kapotte keys had volgens dat tooltje op die wikipagina, dus alsnog maar even vervangen

[Seth4Chaos]

Zwerver schreef op woensdag 14 mei 2008 @ 10:14:
[...]

Nou nee hoor

da:~# rm /etc/ssh/ssh_host*
da:~# /etc/init.d/ssh restart
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Restarting OpenBSD Secure Shell server: sshdCould not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
.
da:~# 

Gelukkig niet zo'n probleem aangezien dat een xen guest is

nope, je hebt gelijk. Dit is op mijn andere server (Gentoo), daar worden ze automatisch bij niet bestaan gegenereerd.

[Creepy]

Wat me overigens net opviel: een apt-get dist-upgrade update je ssh en genereert ook gelijk nieuwe hosts-keys indien nodig. Dit geld alleen voor de SSH host keys, niet voor certificaten.

Edit: en anders lees ik eerst ff alle replies fatsoenlijk door. phobosdeimos melde dit ook al.

[ Voor 20% gewijzigd door Creepy op 14-05-2008 15:16 ]

[cherwin]

Met ssh-vulnkey(1) kan je snel kijken of je een kwetsbaar systeem c.q. keypair hebt. Is handig te scripten als je dit op meerdere machines tegelijk moet doen, bekijk de manpage voor meer informatie.

[edit] En ja hoor, ik zal voortaan ook wat beter de replies doorlezen, met name die van phobosdeimos..

[ Voor 21% gewijzigd door cherwin op 15-05-2008 08:46 ]

[Maasluip]

Waar is ssh-vulnkey? Ik heb de laatste versies van openssh-server en openssh-client op Ubuntu 8.04, maar ik kan geen ssh-vulnkey vinden.

[cherwin]

Maasluip schreef op donderdag 15 mei 2008 @ 07:47:
Waar is ssh-vulnkey? Ik heb de laatste versies van openssh-server en openssh-client op Ubuntu 8.04, maar ik kan geen ssh-vulnkey vinden.

Voor Debian en Ubuntu moet je wel eerst de laatste security patches hebben geïnstalleerd voordat ssh-vulnkey beschikbaar is. Voor meer informatie zie http://www.debian.org/security/key-rollover/

[ Voor 39% gewijzigd door cherwin op 15-05-2008 08:39 ]

[Maasluip]

Ik heb de laatste Ubuntu patches geïnstalleerd (aptitude upgrade), maar ik heb nog altijd geen ssh-vulnkey. Wat ik op Ubuntu met die Debian package moet weet ik niet.

[igmar]

phobosdeimos schreef op woensdag 14 mei 2008 @ 10:29:
De code van openssl gebruikte ergens een stukje "uninitialized memory" in de seed voor hun RNG. Dit wordt gespot door valgrind als een bug, en is door de brave package maintainers van Debian dan ook gefixt als zijnde een bug. Maar hierdoor hebben ze het hele seed mechanisme eigenlijk (onbewust) omzeep geholpen, waardoor de seed voor de openssl RNG in debian al 2 jaar dezelfde waarde is. Met als gevolg dat alle keys aangemaakt tussen toen en nu, perfect voorspelbaar zijn.

't is ook een bug. Op systemen die alle pages in userspace clearen (OpenBSD, Linux met GRSecurity) is het zowiezo niet veilig. D'r van uit gaan dat er random data in het geheugen staat is zowiezo niet correct.

[Creepy]

apt-get upgrade installeerd geen nieuwe packages. Met een apt-get dist-upgrade krijg je wel de blacklist en ssh-vulnkey geinstalleerd.

[Confusion]

Creepy schreef op woensdag 14 mei 2008 @ 11:00:
Updaten dus van al die keys..

In feite staat er in de security announcement zelfs nog iets sterkers: alle machines waarop met keys ingelogged kon worden moeten als gecompromitteerd beschouwd worden en zouden niet gebruikt moeten worden om nieuwe keys te genereren. Er is natuurlijk geen kip die daadwerkelijk alle key-toegankelijke servers opnieuw gaat installeren, maar eigenlijk....

[CyBeR]

Voor de volledigheid, dit is zo'n beetje het effect:

code:

marco@oberon:~$ ssh -i rsa/2048/66a4f07c6b6e4440560dff1b9e958ffd-9835  userdieikzelfnietben@doosvanmij
Linux tstsrv01 2.6.14.4 #1 SMP Wed Dec 21 13:40:34 CET 2005 i686 GNU/Linux

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Last login: Wed May 14 16:32:36 2008 from 136-10.bbned.dsl.internl.net
userdieikzelfnietben@tstsrv01:~$

Deze doos was zelf niet vulnerable, maar een van de users had een vulnerable key in z'n authorized_keys file staan. Een key die ik uiteraard niet van hem gekregen heb. In dit geval heb ik 't mezelf makkelijk gemaakt door even z'n authorized_keys te fingerprinten en de goede te pakken, maar 't is ook heel aardig te bruteforcen. Maximale hoeveelheid mogelijke keys is namelijk net iets meer dan 65000.

[Confusion]

igmar schreef op donderdag 15 mei 2008 @ 09:51:
[...]
D'r van uit gaan dat er random data in het geheugen staat is zowiezo niet correct.

Het is ook niet meer dan een extra bron van entropie, niet een bron die noodzakelijk is voor het verkrijgen van voldoende entropie voor het genereren van veilige keys.

[CyBeR]

Inderdaad. Op zich was het wegcommenten van een van de regels uit de code niet rampzalig. Dan zou er geen ongeinitialiseerd geheugen gebruikt worden, maar da's geen probleem. Het is alleen zo het het ongeinitialiseerde geheugen de randomness helpt (en daarom staat die regel code er nog in), er is geen afhankelijkheid naartoe. Het probleem was het wegcommenten van nog een andere regel code omdat die identiek was aan de andere regel. Echter, die regel zorgde er nu juist voor dat de random ook echt random was in plaats van alleen afhankelijk te zijn van het pid van het proces.

[ Voor 28% gewijzigd door CyBeR op 15-05-2008 10:48 ]

[Robbeke]

interessante topic.

heb zelf ook een linux server op het web maar hier is SSH niet bereikbaar van het publiek, enkel apache met een globalsign cert. en postfix voor mail.

Dat zit dus wel goed denk ik of is postfix een probleem? (staat ook in de lijst)

Toch vreemd dat er zo weinig controle is op code waar het net rond security draait. Nuja, geen enkel systeem is perfect

[Confusion]

CyBeR schreef op donderdag 15 mei 2008 @ 10:47:
Inderdaad. Op zich was het wegcommenten van een van de regels uit de code niet rampzalig. Dan zou er geen ongeinitialiseerd geheugen gebruikt worden, maar da's geen probleem. Het is alleen zo het het ongeinitialiseerde geheugen de randomness helpt (en daarom staat die regel code er nog in), er is geen afhankelijkheid naartoe. Het probleem was het wegcommenten van nog een andere regel code omdat die identiek was aan de andere regel. Echter, die regel zorgde er nu juist voor dat de random ook echt random was in plaats van alleen afhankelijk te zijn van het pid van het proces.

Mooi voorbeeld waarom methoden met onverwachte (laat staan ongedocumenteerde) side-effects zuigen.

[Jaap-Jan]

Maasluip schreef op donderdag 15 mei 2008 @ 07:47:
Waar is ssh-vulnkey? Ik heb de laatste versies van openssh-server en openssh-client op Ubuntu 8.04, maar ik kan geen ssh-vulnkey vinden.

Helpt een reinstall van openssh-client? Hij hoort er wel te zijn, namelijk:

code:

jaapjan@frodo:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04"
jaapjan@frodo:~$ ssh-
ssh-add      ssh-argv0    ssh-copy-id  ssh-keyscan  
ssh-agent    ssh-askpass  ssh-keygen   ssh-vulnkey  
jaapjan@frodo:~$ dpkg -l | grep ssh
ii  openssh-client                             1:4.7p1-8ubuntu1.2                         secure shell client, an rlogin/rsh/rcp repla
ii  ssh-askpass-gnome                          1:4.7p1-8ubuntu1.2                         interactive X program to prompt users for a

Ik heb de RSA en DSA keys voor de server opnieuw gegenereerd.

Ik mag trouwens de rest van m'n SSL certificaten ook opnieuw genereren, zelfs CSR's zijn vulnerable.

[ Voor 8% gewijzigd door Jaap-Jan op 15-05-2008 11:46 ]

[jelly]

Ubuntu Hardy

Gister was er een updat en vanochtend ook misschien heeft deze laatste update het probleem verholpen. Mijn versie is 0.9.8g-ubuntu

ubuntu info

[ Voor 28% gewijzigd door jelly op 15-05-2008 12:07 ]

[Creepy]

Robbeke schreef op donderdag 15 mei 2008 @ 11:03:
interessante topic.

heb zelf ook een linux server op het web maar hier is SSH niet bereikbaar van het publiek, enkel apache met een globalsign cert. en postfix voor mail.

Dat zit dus wel goed denk ik of is postfix een probleem? (staat ook in de lijst)

Toch vreemd dat er zo weinig controle is op code waar het net rond security draait. Nuja, geen enkel systeem is perfect

Als je het certificaat hebt gegenereerd vanaf een server met de vulnarable ssh versie erop dan kan het zijn dat je apache certs ook waardeloos zijn omdat de communicatie m.b.v. deze certs binnen no-time te encrypten is. Controleer dus ook of je certificaat veilig is of niet anders kan iemand die packages tussen jou en je server kan sniffen al je https beveiligde communictie rustig meekijken.

Confusion schreef op donderdag 15 mei 2008 @ 10:11:
[...]

In feite staat er in de security announcement zelfs nog iets sterkers: alle machines waarop met keys ingelogged kon worden moeten als gecompromitteerd beschouwd worden en zouden niet gebruikt moeten worden om nieuwe keys te genereren. Er is natuurlijk geen kip die daadwerkelijk alle key-toegankelijke servers opnieuw gaat installeren, maar eigenlijk....

Om 100% zeker van je zaak te zijn wel ja. Erg vervelend is het wel want je machine kan dus certs hebben die niet goed zijn ondanks dat je geen debian draait.

[ Voor 30% gewijzigd door Creepy op 15-05-2008 13:28 ]

[BCC]

Creepy schreef op donderdag 15 mei 2008 @ 12:51:
Om 100% zeker van je zaak te zijn wel ja. Erg vervelend is het wel want je machine kan dus certs hebben die niet goed zijn ondanks dat je geen debian draait.

Het aantal keys dat OpenSSH nog kon genereren was ook wel ERG klein. Elke useraccount is in zo'n 20 minuten te brute forcen.

[CyBeR]

BCC schreef op donderdag 15 mei 2008 @ 23:58:
[...]

Het aantal keys dat OpenSSH nog kon genereren was ook wel ERG klein. Elke useraccount is in zo'n 20 minuten te brute forcen.

Mits dat account gebruik maakt van keys om in te loggen.

[Robbeke]

Creepy schreef op donderdag 15 mei 2008 @ 12:51:
[...]

Als je het certificaat hebt gegenereerd vanaf een server met de vulnarable ssh versie erop dan kan het zijn dat je apache certs ook waardeloos zijn omdat de communicatie m.b.v. deze certs binnen no-time te encrypten is. Controleer dus ook of je certificaat veilig is of niet anders kan iemand die packages tussen jou en je server kan sniffen al je https beveiligde communictie rustig meekijken.

Dat certificaat is toch gegenereerd door GlobalSign? Of bedoel je dan dat het probleem zich kan voordoen wanneer de initiele request challenge op een vulnerable pc is gemaakt?

Hoe kan ik dit controleren? Met het tooltje eerder in dit topic?

[TrailBlazer]

IK kan me vergissen hoor maar volgens mij worden certificaten enkel gebruikt ter authenticatie en niet voor encryptie. De encryptie keys worden toch on the fly gemaakt.

[CyBeR]

TrailBlazer schreef op vrijdag 16 mei 2008 @ 07:49:
IK kan me vergissen hoor maar volgens mij worden certificaten enkel gebruikt ter authenticatie en niet voor encryptie. De encryptie keys worden toch on the fly gemaakt.

Je vergist je. De certificaten worden namelijk gesigned met asymmetrische crypto.

[Creepy]

BCC schreef op donderdag 15 mei 2008 @ 23:58:
[...]

Het aantal keys dat OpenSSH nog kon genereren was ook wel ERG klein. Elke useraccount is in zo'n 20 minuten te brute forcen.

Dat snap ik maar wat ga je dan allemaal precies doen? Vindt je alleen het useraccount compromised of vind je de hele machine compromised (== volledige reinstall doen om weer 100% zeker te zijn)? Die laatste stap heb ik niet genomen. Wel heb ik alle wachtwoorden veranderd en alle certs opnieuw gemaakt van alle users (en natuurlijk pas de wachtwoorden veranderen als alles is geupdate en je een nieuwe ssh connectie hebt gemaakt)
Direct als Root inloggen m.b.v. een certificaat kan hier niet. Tuurlijk heb ik een probleem als er voordat ik de ssh hosts certs heb aangepast iemand heeft zitten sniffen en m.b.v. een oud wachtwoord zichzelf root heeft kunnen maken maar dat is een risico dat ik op het moment neem.

[ Voor 12% gewijzigd door Creepy op 16-05-2008 10:30 ]

[Confusion]

TrailBlazer schreef op vrijdag 16 mei 2008 @ 07:49:
IK kan me vergissen hoor maar volgens mij worden certificaten enkel gebruikt ter authenticatie en niet voor encryptie. De encryptie keys worden toch on the fly gemaakt.

Certificaten worden enkel gebruikt ter authenticatie, maar jezelf kunnen authenticeren als iemand die je niet bent is natuurlijk net zo goed een veiligheidsrisico.