Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Xs4all stopt met otp-tweestapsverificatie op webmail

Xs4all-klanten kunnen vanaf 1 augustus niet langer tweestapsauthenticatie op hun webmail gebruiken. Klanten hebben een mail gekregen waarin staat dat otp-codes of one time passwords straks niet meer te gebruiken zijn en alleen inloggen met een wachtwoord mogelijk is.

Moederbedrijf KPN heeft de mail, waar een gebruiker Tweakers op attendeerde, naar Xs4all-klanten gestuurd die de Calculator-functie gebruikten. Dat is een feature voor de Xs4all-webmail waarmee gebruikers otp-codes kunnen gebruiken als tweestapsverificatie. Die codes worden gegenereerd door een externe app.

Xs4all zegt dat die functie niet meer zal werken per 1 augustus van dit jaar. "Door een upgrade van ons e-mailplatform bieden wij deze inlogmethode vanaf dan niet meer aan", schrijft het bedrijf. Vanaf die datum kunnen gebruikers alleen nog inloggen met een gebruikersnaam en wachtwoord. Het is niet bekend om wat voor upgrade het gaat, maar KPN zegt dat het om 'een bewuste keuze van Xs4all gaat om deze niet opnieuw te gaan ontwikkelen en aanbieden', omdat er onder klanten 'weinig behoefte' aan de functie was.

Er komt geen alternatief beschikbaar zoals een securitykey of hmac-based one-time password via bijvoorbeeld sms. Xs4all zegt dat klanten kunnen inloggen met hun Mijn Xs4all-hoofdaccount.

Update: reactie KPN toegevoegd.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Tijs Hofmans

Redacteur privacy & security

15-07-2020 • 10:35

172 Linkedin

Submitter: Remcoflr

Reacties (172)

Wijzig sortering
Een oprechte vraag. 2FA op webmail is toch, deels, een wassen neus? Je kunt toch toch nog steeds via IMAP/POP/SMTP inloggen? Of kun je dat uitzetten bij XS4ALL?

Ik ben groot voorstander dat de mail clients oAuth2 gaan ondersteunen voor alle providers, naast O365 of Google. Het lijkt mij dat 2FA op dat moment echt effectief is.
Het is niet echt een wassen neus door de manier waarop wij dat implementeren. Dit is ooit in webmail ingebouwd zodat je op een onveilige computer alsnog kon inloggen. Dit kan omdat je voor webmail, als je OTP gebruikt, niet je normale wachtwoord intikt maar een losse pincode, samen met de 2e factor. Als die pincode lekt (bv door keyboard of wifi sniffer), heeft men daar weinig aan zonder je telefoon of yubikey.

Dit was dus puur een functie voor alleen webmail.
Je noemt de voordelen op als het zou blijven bestaan, maar het gaat over een paar dagen weg en de reactie is dat het standaard gebruikersnaam/wachtwoord over blijft om in te loggen. Hoe zorgt het verdwijnen er dan voor dat xs4all haar klanten beschermt tegen credential stuffing? Zoals ik het lees halen jullie dus iets weg waar jullie al jaren lang over zeggen dat het belangrijk is om te gebruiken en klanten voor aansporen om toe te passen.
Dat was ook mijn conclusie toen ik onderzocht of mijn mailtoegang (niet bij XS4ALL) veiliger kon. Leuk hoor, de voordeur beveiligen (webmail) maar als de achterdeur (IMAP/POP/SMTP) dat niet ondersteunt, dan schiet je er weinig mee op. Misschien leuk tegen de 'toevallige' inbreker. Maar de inbreker die het op jou voorzien heeft slaat de voordeur over en gaat via de achterdeur.

Ben benieuwd of iemand hier nog een ander licht op kan schijnen of het inderdaad die wassen neus is.

[Reactie gewijzigd door JaymzHetfield op 15 juli 2020 11:02]

Voor die achterdeur zijn dan weer de app passwords bedacht zoals bijv. Gmail het nu implementeert. Dan kan je niet meer met hetzelfde wachtwoord bij zowel je webmail met instellingen als je IMAP/POP/SMTP. Waardoor je met bijv. toegang tot de laatste niet per definitie ook dingen kan aanpassen in de instellingen van je mail server via de webgui.

De achterdeur blijft dan onveilig, maar met een wachtwoord dat je op zich nergens anders (hoeft) te gebruiken dan op je specifieke apparaat / client. Per apparaat is vervolgens de toegang in te trekken door het app password inactief te maken.

Dat is nog steeds geen TFA, maar wel een stuk veiliger. En inderdaad, pakketten zoals Mailcow, waarmee je je eigen mailserver opzet, ondersteunen het jammer genoeg niet.

[Reactie gewijzigd door CurlyMo op 15 juli 2020 19:50]

App passwords zijn bedoelt voor zeer oude programma's zoals Office 2010 en Apple Mail (<iOS 11) en die niet werken met Multifactor Authenticatie. Moderne client programma's kunnen echter gewoon overweg met MFA...

'Legacy authenticatie' zoals Microsoft het benoemt, is iets dat bijvoorbeeld Microsoft en Google helemaal aan het uitfaseren zijn. Het is onveilig en je moet het niet gebruiken.
Onzin, app passwords zijn voor alle externe mail clients nuttig, oud of nieuw, IMAP werkt namelijk niet met MFA. Je kunt MFA alleen gebruiken met een web client (bij moderne mail clients kun je wel met MFA inloggen, maar dat wordt dan onder water omgezet in een IMAP app password)
Nee, jij spreekt onzin :+ , je hebt duidelijk geen inhoudelijke kennis van de materie.
Spreek anders even Microsoft of Google tegen:
Google:
Sign in with App Passwords

Tip: App Passwords aren’t recommended and are unnecessary in most cases. To help keep your account secure, use "Sign in with Google" to connect apps to your Google Account.

An App Password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App Passwords can only be used with accounts that have 2-Step Verification turned on.


Microsoft:
If you have applications, such as Office 2010 or earlier and Apple Mail before iOS 11, that don't support an additional verification, you must set up an app password. See manage app passwords for more information.

App passwords is een manier om oude legacy clients te ondersteunen die geen moderne authenticatie ondersteunen. Het is natuurlijk niet 'nuttig' of betrouwbaarder dan MFA. Het hele principe van app passwords nodig hebben is een gebrek aan veiligheid aan de client zijde en moet alleen ingezet worden als een 'last resort'. Als onderbouwing:

App-wachtwoorden
Bepaalde oudere, niet-browser-apps begrijpen onderbrekingen of onderbrekingen in het verificatie proces niet. Als een gebruiker is ingeschakeld voor multi-factor Authentication en probeert een van deze oudere, niet-browser-apps te gebruiken, kunnen ze meestal niet goed worden geverifieerd. Met een app-wacht woord kunnen gebruikers zonder onderbreking blijven verifiëren met oudere, niet-browser-apps.


Microsoft werkt tegenwoordig met 'Security defaults'. Hierbij worden alle oude onveilige authenticatie en communicatieprotocollen uitgeschakeld. Raad eens wat hierbij zit? App password...

maar dat wordt dan onder water omgezet in een IMAP app password
Dit is een volledig verkeerde interpretatie van hoe moderne authenticatie protocollen werken. Ik raad je aan om te beginnen met inlezen op OAuth.

Ik kijk uit naar je onderbouwde reactie met bronnen waarin je het tegendeel bewijst.

[Reactie gewijzigd door dycell op 15 juli 2020 16:23]

90%+ van alle mail clients gebruikt IMAP, en dat heeft toch echt geen oAuth. Bron: https://tools.ietf.org/html/rfc3501

oAuth wordt door modernere mail clients wel gebruikt om een app password te downloaden dat vervolgens door IMAP gebruikt kan worden.
90%+ van alle mail clients gebruikt IMAP, en dat heeft toch echt geen oAuth
En dan geeft hij een RFC van IMAP. Lol, dat zegt toch helemaal niets van de zin die je gooit..

oAuth wordt door modernere mail clients wel gebruikt om een app password te downloaden dat vervolgens door IMAP gebruikt kan worden.
En hij heeft niet eens de Wiki erbij gepakt....

OAuth maakt gebruik van tokens, waardoor vertrouwelijke gegevens als een gebruikersnaam of wachtwoord niet afgegeven hoeven te worden. Elk token geeft slechts toegang tot specifieke gegevens van één website voor een bepaalde duur. Zo kan ingesteld worden dat een bepaald programma slechts een jaar toegang heeft tot de gegevens. Hierna kan eventueel opnieuw toegang worden gevraagd.
Ja, dat weet ik echt wel (heb al meerdere oAuth clients in elkaar gezet, vindt het geen fijn protocol overigens). Die oAuth token is in het geval van email clients niet time limited, en is dus het app password dat vervolgens met IMAP gebruikt wordt.

(Ik had die RFC er even bijgedaan zodat je kon zien dat IMAP single factor is niet multi-factor)

[Reactie gewijzigd door Speleding op 16 juli 2020 16:06]

Een app password wordt toch meestal gebruikt voor automatische authenticatie mechanismen via API's. Daarbij tik je moeilijk een OTP in.
Heb je daar bronnen voor waar ik daar verder over kan lezen? Ik ken MFA namelijk niet als onderdeel van IMAP/POP/SMTP dus leer graag wat bij :)
Sorry, ik was denk ik niet geheel duidelijk maar MFA werkt inderdaad niet met oude protocollen. Microsoft en Google zijn bezig om deze legacy protocollen uit te faseren.

..The numbers on legacy authentication from an analysis of Azure Active Directory (Azure AD) traffic are stark:
More than 99 percent of password spray attacks use legacy authentication protocols
More than 97 percent of credential stuffing attacks use legacy authentication
Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled


Hun oplossing is om enkel clients te ondersteunen die moderne authenticatie protocollen ondersteunen, toe te staan. Hier is het bericht van Google.

[Reactie gewijzigd door dycell op 15 juli 2020 15:25]

Ik lees inderdaad dat ze beide de oude protocollen willen uitfaseren, maar geen beschrijving of lijst van de nieuwe protocollen die ze gaan vereisen. Of lees er overheen :)
Nee, dit bericht is inderdaad enkel bedoeld als waarschuwing (en planning) om oude protocollen uit te schakelen. De term 'moderne authenticatie' is best breed.
Zie ook microsoft's uitleg hier: Account setup with modern authentication in Exchange Online

Modern authentication is an umbrella term for a combination of authentication and authorization methods. These include:
Authentication methods: Multi-factor Authentication; Client Certificate-based authentication.
Authorization methods: Microsoft's implementation of Open Authorization (OAuth).


Modern authentication is enabled through the use of the Active Directory Authentication Library (ADAL). ADAL-based authentication is what Outlook for iOS and Android uses to access Exchange Online mailboxes in Microsoft 365 or Office 365. ADAL authentication, used by Office apps on both desktop and mobile devices, involves users signing in directly to Azure Active Directory, which is the identity provider for Microsoft 365 and Office 365, instead of providing credentials to Outlook.

ADAL-based authentication leverages OAuth for modern authentication-enabled accounts


Uiteraard heeft Google zijn eigen ding maar het is ook compatible met OAuth
Dan moet je (net als bij bv Gmail) neem ik aan alsnog je otp invoeren? Ken Xs4all-webmail op zichzelf niet goed genoeg maar kan me voorstellen dat dat zo werkt.
Nee deze oude protocollen ondersteunen geen 2fa... Zijn vrij basale protocollen hoor, je kan zelf via telnet nog wel een mailtje typen en versturen als je wil.

Andere leveranciers hebben 2fa op de webmail en daar kun je dan one-time password aanmaken voor pop3 / imap toegang. Zo moet iemand die enkel je wachtwoord weet alsnog inloggen met 2fa om achter je pop3/imap wachtwoord te komen.

De facto heb je dan dus wel 2fa bescherming.

ZIe ook: https://support.google.com/accounts/answer/185833?hl=nl
Laten we voor het gemak even OAuth vergeten. Je hebt echt geen app password nodig voor email clients en providers (Google oa) die OAuth ondersteunen (zoals Postbox en Thunderbird). En ja, dan maak je gewoon gebruik van IMAP/SMTP.

[Reactie gewijzigd door Ventieldopje op 15 juli 2020 12:02]

Ik vergeet OAuth niet maar het is geen oplossing voor de tekortkoming van het protocol pop3/imap...

Sterker nog, OAuth is gewoon een methode om jouw client een app password je laten genereren. Noemen ze tokens geloof ik.
Authenticatie voor IMAP kan prima obv OAuth als server en client dat ondersteunen.
De facto heb je dan dus wel 2fa bescherming.
Defacto is dat nog steeds geen TFA, want zodra bijv. je Thunderbird client onbeheerd open laat staan, kan je nog steeds vrij makkelijk je app password inzien.
Zie '2fa-bescherming' als één woord.

Het klopt dat het geen TFA/2FA is, maar het komt er in de praktijk bijna op neer omdat je een eenmalig wachtwoord gebruikt dat je daarna nooit meer ergens invult.

Zoals je zelf aangeeft is een van de weinige mogelijkheden het wachtwoord verkrijgen van de 2 eindpunten, de client (thunderbird) of server.

Maar als iemand bij je thunderbird kan om je wachtwoord uit te lezen dan kunnen ze ook bij je gmail, want die logt automatisch in. :)
G Suite kent wel degelijk ook TOTP. Je moet alleen eerst verificatie met een telefoon doen voordat je het kan toevoegen. Eenmaal toegevoegd kun je het gekoppelde telefoonnummer verwijderen, de TOTP blijft staan. :)

Een app password is namelijk alleen in te stellen als er tweetrapsauthenticatie is toegevoegd aan het betreffende account.

[Reactie gewijzigd door CH4OS op 15 juli 2020 11:26]

Zeer goede vraag. Jammer dat Tweakers liever KPN gaan bashen dan dat ze hier bij stil staan. Kan je net zo goed elk e-mail programma afkraken dat er geen tweestapsverificatie is om in te loggen op je mailaccount. Sowieso is het hele e-mail protocol standaard onveilig, dus het is lekker makkelijk om KPN af te zeiken. Klaag dan dat een stel sukkels 60 jaar geleden zo'n lek systeem hebben verzonnen.
+1Anoniem: 951889
@Droefsnoet15 juli 2020 11:34
Kan je net zo goed elk e-mail programma afkraken dat er geen tweestapsverificatie is om in te loggen op je mailaccount.
Ja, dat kan ook net zo goed. Want het is kwalijk als dat er niet in zit. (Al dan niet optioneel)
Sowieso is het hele e-mail protocol standaard onveilig, dus het is lekker makkelijk om KPN af te zeiken. Klaag dan dat een stel sukkels 60 jaar geleden zo'n lek systeem hebben verzonnen.
Dat is waarom je bij veel providers een apart password kan kiezen voor pop/imap. De enige plaats om je settings en ww aan te passen is via de webmail (dus moet je door 2FA heen) en bij pop/imap vul je het wachtwoord toch maar 1x per apparaat in, dus maak je er een monster van 64 unicode karakters van. Dat is nog steeds minder veilig dan volledig 2FA omdat het app password in theorie compleet gestolen kan worden als een apparaat gehackt is, maar die kans is veel kleiner dan dat het word gebruteforced. Als ze nou echt deftig zijn kan je een apart password per apparaat instellen en via de web interface apparaten verwijderen.

Dus ja we kraken KPN af want er zijn een flink aantal dingen mogelijk die de beveiliging in de goeie richting duwen, in plaats van deze luie actie om de boel maar terug te draaien. Of het nou onkunde is of opzet, XS4ALL is niets anders meer dan een merk en iedereen die er zat vanwege de meerwaarde doet er goed aan om daar weg te wezen.
XS4ALL is niets anders meer dan een merk en iedereen die er zat vanwege de meerwaarde doet er goed aan om daar weg te wezen.
Dat is pas interessant als het alternatief hetzelfde is als het oude XS4all of beter dan het huidige XS-KPN-4all. Ik heb het nog niet kunnen vinden. Freedom is een prachtig alternatief, maar ze bieden TV via Canal Digitaal. Daar ga ik dus niet aan beginnen.
Freedom gebruiky Canal Digital voor TV én heeft bij CD bedongen dat die op geen enkele wijze het kijkgedrag van de klanten via Freedom gaan volgen. Het is een goed voorbeeld van hoe een ISP - tegenwoordig dus vooral system integrator - voor de belangen van haar klanten op kan komen.
Ik ben bang dat anders dan bij Freedom de meeste ISP maar al te graag de derdenaanbieders niets in weg leggen, zeker niet als zij nog ook een kickback of korting (voor de ISP zelf) kunnen bedingen.
0Anoniem: 951889
@Arjan P15 juli 2020 12:54
Je kijkt nog TV? :/ Kan je dan niet een pakket zonder TV nemen, en dat elders afnemen? :O
Zou kunnen, maar ook dat is dus een alternatief dat minder is dan wat ik nu heb..
En ja, zoals miljoenen nederlanders kijk ik 'nog' TV.
OAuth is ook niet heilig, iemand onderschept je pakketje, je wijzigt je wachtwoord, die iemand stuurt het pakketje nogmaals en krijgt succes (met lezen of schrijven). Ik snap dat het idee achter OAuth ook is, dat het wachtwoord onafhankelijk is, maar ik krijg altijd wel een slecht gevoel hierbij....
Dat ligt niet echt aan OAuth, maar aan de website zelf dan. Elke service die z'n veiligheid serieus neemt zal de tokens resetten zodra het wachtwoord verandert. Zo doet Google het bijvoorbeeld ook. :)

Bij technieken als JWT is het inderdaad wat moeilijker om tokens te revoken. Daar moet je wachten tot ze expired zijn, of server-side gaan blacklisten.
Interessant. In dit geval ging het om onedrive 4 business.
ik zou zeggen, dat ligt wel on OAth. als er een onveilige implementatie default is, is dat een probleem van de standaard. niet aan mensen om dat vervolgens te fixxen.
Je kan oAuth 2 gebruiken in combinatie met mail protocollen, maar zowel server als client moeten het ondersteunen. En uiteraard moet basic authentication uitstaan aan de server side.
"Door een upgrade van ons e-mailplatform bieden wij deze inlogmethode vanaf dan niet meer aan"
Upgrade > 2FA verwijderen? :+
Ik gok een upgrade van hun webmail-platform naar een andere software, die blijkbaar geen 2FA ondersteunt.
Best kwalijke zaak, want in deze tijd zou dit gewoon een eis moeten worden. Het feit dat weinig mensen het gebruiken speelt geen rol, je moet het ook dan actief promoten. Vooral bij XS4ALL waar security hoog in het vaandel staat vind ik het opvallend dat ze dit laten schieten, maar dit zullen wel de eerste dingen zijn waarbij alles steeds meer richting KPN getrokken wordt.
Als security hoog in het vaandel staat gaat het er vooral om dat die security een voldoende toegevoegde waarde heeft om risico weg te nemen en niet een vorm van schijnveiligheid is.

Bij een provider log je gewoonlijk met 1 soort gegevens in op verschillende diensten en kan dat ook op verschillende manieren. Webmail is toegang tot de mail via een webinterface terwijl je er op heel veel andere manieren (pop/imap/smtp) via apps of applicaties ook bij kan. Wat heeft die 2FA op alleen de webmail dan als betekenis voor beveiliging als een crimineel je gebruikersnaam en wachtwoord van de provider ergens tegen komt? Vast wel een beetje betekenis voor niet zo slimme criminelen, maar verder erg weinig.

Ik ben het met je eens dat 2fa een eis kan worden. Maar dat is het nog niet en dat zal het ook niet makkelijk worden als veel toepassingen niet voor gemak met 2FA gemaakt zijn. Bij veel mailservice die gebruikers massaal op de achtergrond gebruiken (pop/imap/smtp) is het nog niet gewoon dat 2FA gebruikt kan worden. Die gebruikers gaan niet iedere synchronisatie een otp genereren en invullen om hun mail te lezen. Er zijn geen veelgebruikte apps voor algemene maildiensten om otp op de achtergrond te regelen en misschien moet je dat ook niet willen omdat de gebruiker er dan niet meer tussen zit. Dan kan je wel stellen dat 2FA zal moeten maar daarmee klaag je alleen maar.
En daarvoor zijn applicatie-specifieke credentials bedacht! Dan kun je prima je frontend van 2FA voorzien, met de inloggegevens die een kwaadwillende buit heeft gemaakt kan men dan nog steeds niet bij de gegevens via IMAP/SMTP/POP(...) komen. Ja - dat is een ander verhaal als ze die credentials bemachtigen, maar volgens mij gaat er iets goed mis als je applicatie-specifieke credentials (er van uitgaande dat deze gegeneerd worden aan de provider kant) gebruik voor andere zaken 8)7. Dan is 2FA imho je minste zorg :).

N.B. geen idee overigens of XS4ALL dit had geïmplementeerd, ik ben geen klant bij ze.
Edit: ik ben het dus niet oneens met je, maar de waarheid ligt iets genuanceerder.

[Reactie gewijzigd door Nexz op 15 juli 2020 14:41]

Bij Xs4all betaal je op het moment 69,50 voor 500Mbit down/up.
Bij KPN betaal je op het moment 65,- voor 1000Mbit down en 500Mbit up.
Naast de extra huur kosten voor een fritzbox en zelfs een abonnement op helpdesk support is het nog steeds goedkoper om over te gaan naar KPN.
Dat ze nu beveiligingen uitschakelen en er niks voor in de plaats bieden is alleen maar een teken dat xs4all waarschijnlijk eerder dan later volledig de nek om gedraaid wordt.
Ik had het laatst bekeken, maar met alle rompslomp als Fritzbox en 2 TV tuners kwam KPN duurder uit dan XS4ALL in mijn geval.
Als ze beide dezelfde snelheid hebben dan klopt dat ja.
Zoals ik aangeef gaat het om een verdubbeling van snelheid dus als je bij KPN 5-10 euro meer zou betalen voor het hele pakket met alle toeters en bellen maakt het weinig uit want je heb bij KPN 500Mbit extra/gratis wat totaal niet in verhouding ligt.
Ik heb het laatst bijna gedaan precies om de redenen welke jij aankaart.. Had de aanvraag al ingediend bij KPN en wat ben ik achteraf blij dat ik het niet gedaan heb. KPN blijft een zooitje ongeregeld.

Mijn annulering, ondanks de bevestiging van deze annulering, was helemaal niet doorgevoerd. Typisch KPN.

Ook typisch XS4ALL dat zij mij in anderhalve week meermaals hebben opgebeld en mij toch echt hebben geadviseerd er achteraan te gaan bij KPN en het niet van hen af te laten hangen, omdat ik in het slechtste geval met 2 abonnementen opgescheept zou zitten.

Als het op voorhand annuleren al zoveel extra werk kost dan kunnen wij zelf wel invullen als het achteraf annuleren voor moeite zou kosten nadat het termijn verlopen zou zijn.

In the end heb ik nu een abonnement bij XS4ALL welke 2 euro's per maand minder kost dan de KPN variant. Met Fritxbox en Fritz repeater.

Mijn conclusie na deze actie is dat XS4ALL voor nu nog steeds "XS4ALL" is en KPN nog steeds echt KPN.
Ik had al mijn twijfels, maar ik gokte het er op. Via mijn werk heb ik veel met KPN te maken en soms is het om moedeloos van te worden.
Sommige takken niet. Hun zakelijke mobiele tak heeft echt een top systeem, top support en goede administratie!
|Je vraagt je bijna af of ze dit soms hebben uitbesteed aangezien het niet strookt met "de rest" van KPN.

Deze actie mbt de mail kan ik echter helemaal niet plaatsen. Dat is niet echt "des XS4ALL".

[Reactie gewijzigd door Mit-46 op 15 juli 2020 15:01]

Ik ben er zelf nog niet over uit wat ik ga doen. Ik zit nog bij xs4all maar zolang een goed alternatief uitblijft wil ik er niet aan vast zitten voor een jaar om hetzelfde te krijgen.
Zoals je zegt is KPN vaak moedeloos maar het "echte" alternatief ziggo is in mijn optiek een absolute no-go.

Xs4all is nu simpel weg KPN in hart en ziel. Op papier is het nu volledig onderdeel van KPN en letterlijk niks anders als een merknaam. Als je dan je eigen merknaam de grond in boort door het volledig mank te laten concurreren met je eigen merk dan is het vrij duidelijk dat ze ervan af willen...maar verkopen willen ze ook niet.
Het lijkt erop dat er ergens en geldezel is die het naam van de markt wil verbannen en het titel "premium internet" wil jatten.
Vermoedelijk zit je niet op nog een overstap te wachten, maar kijk eens op freedom.nl.
Zij hebben geleerd van XS4ALL en daarom is Freedom zo opgezet dat, ook als het zou worden verkocht, niet onder haar eigen hoge normen uit kan. Bijvoorbeeld, de domeinnaam wordt door Bits of Freedom onder stringente voorwaarden aan Freedom beschikbaar gesteld.

[Reactie gewijzigd door Joep Lunaar op 16 juli 2020 11:32]

Vooral bij XS4ALL waar security hoog in het vaandel staat vind ik het opvallend dat ze dit laten schieten,
Vooral bij XS4ALL waar security hoog in het vaandel STOND vind ik het opvallend dat ze dit laten schieten,

Het is nu gewoon KPN.
Ik gok een upgrade van hun webmail-platform naar een andere software, die blijkbaar geen 2FA ondersteunt.
Ik gok dat het een sidegrade is naar het webmail-platform van KPN (die blijkbaar geen 2FA ondersteunt)...
+1Anoniem: 1350842
@AW_Bos15 juli 2020 15:37
Deels mee eens, aan de andere kant vinden klanten het alleen maar vervelend als jij gaat pushen op 2FA. Over het algemeen wordt verplichte 2FA bijvoorbeeld gezien als irritant, voor mij is verplicht bijvoorbeeld ook wel een reden om het niet te gebruiken afhankelijk van de dienst.
Ik denk dat het meer partijen moeten zijn die het als third party aanbieden die het moeten pushen, niet de provider waar mensen geen keuze in hebben soms. Want Nederlanders zijn goed in 1 ding, zeiken zeiken zeiken en zeiken. Als KPN dit actief gaat promoten, moet je eens zien hoe snel niet-tweakers het weer allemaal kut vinden en ze weer 'gedwongen worden door de enge grote bedrijven, terwijl het strong-independent boeren zijn'
En het is ook niet echt nieuws.
De nieuwe mail draait al een jaar.
Ze gaan nu roundcube uitschakelen.
Ik vermoed dat ze het zelf ingebouwd hebben bij xs4all, maar dat die mensen nu ergens anders werken. En het werkte niet na een upgrade -> dus gooien we de boel er maar uit, want de kennis om dat te fixen is het huis uit of het is geen prioriteit meer.
Het huidige webmail lijkt roundcube te zijn. Dat heeft mogelijkheid voor 2FA. Het nieuwe platform lijkt het opensource alternatief OX App Suite en heeft ook 2FA. Als je het wil intergreren zal het dus niet perse hoeven gaan of ze het zelf ontwikkelen maar eerder om andere factoren. Bijvoorbeeld wat die 2FA voor zou stellen als het alleen in de webmail zit terwijl je op andere diensten niet met 2FA kan inloggen. Ik denk dat xs4all geen voorstander is van schijnveiligheid waarbij je via pop/imap/smtp bij dezelfde gegevens kan zonder 2FA en dat waarschijnlijk ook niet snel zal veranderen.
Dat xs4all met roundcube werkt is geen geheim. Volgens mij dragen ze ook redelijk bij aan de ontwikkeling van roundcube.

Bij het gebruik van pop/imap/smtp is het belang van 2fa (iets) minder belangrijk omdat je bij het gebruik van die protocollen na de eerste keer configuratie van de app, je het wachtwoord niet meer hoeft in te tikken. Het afkijken van een wachtwoord is dus minder van toepassing. Bij een web-interface ligt dat iets anders, zeker als je ook uit gaat van kiosk-systemen, wat bij pop/imap/smtp niet zo snel voor komt.

Eerlijk is eerlijk, de 2fa bij xs4all heb ik ook nooit ingesteld. Misschien wel omdat ik de web-interface praktisch niet gebruik. Mijn voorkeur gaat uit naar een mail-applicatie zoals thunderbird.

Wel jammer dat kpn hiermee duidelijk de belofte schend dat ze de services als van ouds zouden laten. Helemaal als ze op de 'nieuwe' webinterface wel 2fa zouden moeten kunnen aanbieden. Hadden ze beter eerst dat kunnen activeren en daarna de xs4all klanten overzetten. Dan is het gewoon een andere vorm van 2fa.
Bij het gebruik van pop/imap/smtp is het belang van 2fa (iets) minder belangrijk omdat je bij het gebruik van die protocollen na de eerste keer configuratie van de app, je het wachtwoord niet meer hoeft in te tikken. ..... Bij een web-interface ligt dat iets anders
Een van de belangrijke redenen om 2FA te gaan gebruiken: zorgen dat criminelen een drempel hebben die zo hoog is dat er nauwelijks waarde in zit om ook die drempel te nemen. Niet het gevoel van schijnveiligheid opwekken omdat je bij de voordeur voor heel veel geld een extra slot hebt terwijl alle ramen en deuren met alleen de gekopieerde sleutel zijn te openen om alsnog bij de waardevolle diensten en informatie te komen. Hoe hou je daar rekening mee door alleen te kijken naar de invloed op heel specifieke implementatie? Stel die klant gebruikt werkelijk alleen webmail met 2FA en hergebruikt de gegevens niet voor andere diensten. Wat schiet die klant er dan mee op als een crimineel alsnog toegang tot die gebruikersnaam en wachtwoord heeft? Hopen dat die niet ontdekt dat die 2FA meestal niet nodig is om het alsnog te kunnen gebruiken?

En hoe staat dat volgens jou dan in verhouding tot de kosten die een provider waarschijnlijk moet maken om dat in stand te houden en doorberekenen aan klanten? Zit daar misschien ook de zoveelste vraag aan de helpdesk bij om uit te leggen waarom die 2FA niet op imap werkt en waarom inloggen via andere services dan niet uit kan als iemand 2FA wil gebruiken?
... heel verhaal.
Kun jij dan ook heel simpel uitleggen waarom dit door xs4all is ingevoerd en blijkbaar prima werkte. En het nu, net na de integratie bij KPN, een véél beter idee is om het er weer af te gooien?

Als ik je posts zo zie zou ik denken dat je bij KPN werkt. Je bent wel erg stellig in het verdedigen van de moeder, terwijl ik geen enkele reden zie dat de klagers niet gewoon gelijk hebben.

En moeilijke config en vragen is natuurlijk nonsens: bij xs4all zaten gemiddeld genomen gebruikers die meer verstand van dit soort dingen hadden dan andere providers. Ook is het opt in, doe je dat dan snap je ook hoe het werkt en dat dit niet op gaat voor smtp/imap.

2FA kost echt helemaal geen drol meer, ook niet voor een grote userbase. De reden er achter is doodsimpel: KPN integreert de mail met hun platform. Daar draait geen 2FA en ze willen niet de moeite doen om dat er wel op te zetten omdat het voor de overall KPN klant niet echt van meerwaarde is. Simpel.
Beveiliging is geen simpele kwestie van het kan helpen dus is het altijd goed. Een airbag is ook een concept dat in relatief goedkope vormen beschikbaar is om een beveiliging te zijn, maar het maakt wel uit hoe je het toe past omdat er ook negatieve kanten aan zitten die een te groot risico zijn. Je wil waarschijnlijk niet dat die airbag iemand verstikt of erger zal verwond dan dat het goed doet. Bij die airbags is daar iets op gevonden: standaardisatie en verplichting hoe het toegepast moet worden. Daarmee nemen de risico's af en kunnen andere risico's afnemen. 'Helaas' is dat bij 2FA nog niet helemaal het geval. 2FA is een concept om een beveiliging in te richten. Er zijn standaarden voor, mensen raken bekend met de voordelen van het concept, providers promoten 2fa (doet xs4all ook al 8 jaar of langer), er bestaan ook goedkope implementaties voor. Maar dat is slechts een kant van het verhaal en de wereld van beveiliging of klant zijn bij een provider bestaat niet alleen maar uit die kant die jou bevalt. De wereld zo benaderen is niet echt gericht op het beheersen van risico's. Aan de reacties te zien ben ik daarin niet de enige die zo over beveiliging denkt. Lees die reacties eens door en je ziet dat er bij 2FA wel iets meer komt kijken dan jij ziet.

Als je aan me zou vragen of ik voorstander van 2FA ben dan is mijn antwoord ja. Maar het zit complexer in elkaar dan het kan helpen en dus is het goed of ik vind iets en dus zal dat het ook wel zo negatief of positief zijn en anders ben je voor een bepaalde partij of komt het door een overname.

[Reactie gewijzigd door kodak op 15 juli 2020 17:47]

Maar die veiligheid kan je ook met IMAP maken. Google doet dat via een app specific password. Als je dan 2FA op de IMAP client hebt of op de device zelf, is dat net so veilig als je 2FA op de webmail hebt.
Google heeft wel vaker meer geld, meer tijd, meer macht om iets te doen of van klanten te verwachten. Dat zit bij een provider dat in een land aan een select groep klanten diensten levert meestal wat anders. Iets willen of technisch kunnen wil nog niet zeggen dat het de investering waard is om het zelf te gaan doen. Bedenk wat er nodig is om alle diensten om te krijgen naar 2FA en de klanten tevreden te houden op het gebied van gemak en veiligheid. Wat zou jij bijvoorbeeld zeggen tegen klanten die veelgebruikte software voor hun mail gebruiken maar waarvoor geen oplossing is zoals google het gemakkelijk gemaakt heeft? Beste klant, jammer van uw investering in die software maar om bij ons gemakkelijk 2FA te gebruiken zal u andere software moeten gebruiken of genoegen moeten nemen met ongemak?
Google doet dat via een app specific password
Dat is gewoon een heel lang gegenereerd wachtwoord. Die als het goed is alleen encrypted wordt verstuurd. Maar dat is niet hetzelfde als 2FA. Voor imap en smtp is ook geen "echte" 2FA mogelijk. Tenzij je serverside iets gaat doen met conditional access ofzo.

Maar goed: een super lang wachtwoord die nergens wordt opgeslagen verder kan prima net zo veilig zijn als 2FA. Maar het is het niet :P
Maar je kan het gebruiken zonder je gebruikersnaam en wachtwoord van Google en 2FA op de mailclient of device zelf zetten. Dan is het effectief ook gewoon 2FA.

[Reactie gewijzigd door NotCYF op 16 juli 2020 09:16]

Als dat zo is, dan is van groot belang te weten of de ondersteuning van sieve filters gehandhaafd blijft.
Krijg ook een beetje het idee dat dit de eerste stappen zijn om de e-mail van XS4ALL naar het kpnxchange platform te verhuizen
Weet je nog dat KPN zij dat er niets aan XS4ALL zou veranderen en dat het alleen zou betekenen dat de "kwaliteit" van KPN mee zou gaan met die van XS4ALL.

Dit is wat ik al verwachte mooie woorden die niet worden na geleefd. Aan het eind is het voor hun toch makkelijker om het gelijk te trekken met de KPN standaard. Weg XS4ALL.
Dat soort leugenachtige PR praat neem ik al ruim 20 jaar niet meer serieus.. Dit is al de 3e ISP overname die ik meemaak en elke keer zie je dat de overgenomen ISP volledig verdwijnt in het "moederbedrijf", waarmee dus ook nagenoeg alle specifieke services en diensten die het bedrijf aanbod.. Zaken als gegarandeerd vast IP-adres etc zullen uiteindelijk ook wel een keer sneuvelen, of KPN dwingt je over te stappen op een veel duurder zakelijk abonnement ofzo.. Ik blijf zolang als de service aan mijn verwachtingen voldoet, zodra dat niet meer zo is ben ik weg..
De vorige isp-overname die ik heb meegemaakt staat nog steeds: van demon.nl naar xs4all.nl. Ik gebruik nog steeds de demon.nl mail adressen. Het zal mij benieuwen wanneer ik een bericht krijg dat die niet meer gaan werken, en vooral hoe bot dat gaat gebeuren. Ik vrees het ergste.
"gegarandeerd vast IP-adres" zal juist niet gaan sneuvelen. Binnen een jaartje of 10 is alles IPv6 en heb je zelfs hele lijsten van IP-adressen die je vast kan gebruiken.
Dat vroeg ik mij ook af, of dit iets heeft uit te staan met een migratie naar een ander mailplatform.

Als dat MS Exchange is, dan kunnen de IMAP gebruikers hun borst nat maken. Op outlook.office365.com kunnen veel accounts vaak (dus niet altijd) effectief niet meer dan 1 IMAP client tegelijkertijd gebruiken, zie [1] en [2]. Schijnt te maken hebben met gebreken in het sessie management en bij gebruik van eigen domeinen.

[1] onderaan pagina https://support.microsoft...1d-42b8-9564-9c414e2aa040
[2] interessante analyse op https://answers.microsoft...39-48dd-81a1-7f8dd5a91a17
hou op schei uit. gisteren 25 (!) minuten in de wacht gestaan, krijg ik zo'n nitwit aan de lijn die zegt dat "er helemaal niets verandert aan de infrastructuur" na de integratie. En me bovendien niet kon helpen. Maar ze kon me ook niet vertellen waarom ik 25 minuten moest wachten.

ik ben founding member van Freedom, tot nu toe dacht ik t even aan te zien, maar het wordt steeds duidelijker. Xs4all begint meer zwarte randjes te krijgen, en het geel is aan het vergroenen.
Begrijp je frustratie, echter vind ik je reactie enigszins denigrerend. Ze had kunnen navragen of er iets veranderd is of gaat veranderen dat ben ik met je eens, echter kan het menske aan de wachtijd van 25 minuten zelf vrij weinig doen, dit heeft puur met bezetting te maken. Menske zit er ook maar om wat brood op de plank te krijgen, en zit er absoluut niet voor haar plezier neem dat maar van me aan.
je hebt gelijk. ik moet beter op mn woorden letten. Dat heeft ze niet verdiend. Ik ben ook gewoon beleefd gebleven, al moest ik soms op mn handen zitten. Haar communicatie kon beslist beter. Vooral toen ze begon over de wachtrij, dat volgens haar info die helemaal niet zo lang was, en wat andere inhoudelijke antwoorden op mijn probleem

enniewee. bedankt voor de feedback. Was niet zo bedoeld.
Offtopic, maar respect voor je reactie!
Alsnog kunnen ze dan vertellen waarom iemand moest wachten; als het goed is heb je inzicht in de queues. En ehm... De legende / sage / fabel is dat ze er bij xs4all juist wel voor hun plezier zitten... Dan is het natuurlijk aan KPN om dat verhaal hoog te houden,samen met al de rest van hun marketingverhaaltjes. Iedereen voorspelde (aan de hand van het verleden bijvoorbeeld) dat dat nooit zou lukken.

[Reactie gewijzigd door mae-t.net op 15 juli 2020 13:34]

Denigrerend? Wat peter schreef was zelf een compliment voor zo'n nitwit, dat ze voor XS4ALL de telefoon mag opnemen. Ze zal er daar niet voor haar plezier zitten, dat doet niemand die bij KPN werkt. Denk dat de gemiddelde XS4ALL'er meer weet dan de slimste KPNer.
Normaal heb je bij XS4ALL zo contact, maar nu duurt het al veel langer dan normaal. Dus KPN haalt mensen weg. En vervangt ze door PC-Prive cursisten en mensen die een script voor lezen.
Peter bood zelfs zijn excuses aan voor zijn reactie top!. Uit eigen ervaring weet ik overigens dat ze er niet met scripts werken dus dat is een aanname :-)

Ze gebruiken er echter wel bepaalde stappenplannen mocht je dat bedoelen.

[Reactie gewijzigd door WhiteRose op 17 juli 2020 16:04]

dat vind ik ECHT bullshit,

natuurlijk zit je niet voor je lol als helpdesk of consumentenafwimpelaar bij toko's als de aldi, de lidle, wish of kpn/xs4all - aan de andere kant als jij gaat werken voor zo'n toko moet je je toch eens bewust zijn dat je met opgefokte boze klanten te maken krijgt vooral bij kpn/xs4all want die leveren niet alleen prut maar vragen daar ook nog eens dubbel de hoofdsom voor.

dat wil niet zeggen dat je dan maar alles door die telefoon kunt roeptoeteren, maar tegelijk mag je best even achter je oor krabbelen en denken 'deze meneer is oprecht pissig en wat hij nu zegt is niet persé aan mijn adres maar aan dat van het bedrijf. laat ik eens proberen die arme stakker ECHT te helpen.

Ter referentie ik heb een jaar voor een advocaat gewerkt en wat ik te horen kreeg als de rechter anders heeft beslist..... of wanneer wij als kantoor iets echt hadden verprutst. - soms moet je ook gewoon een dikke huid hebben en dingen kunnen relativeren

[Reactie gewijzigd door i-chat op 15 juli 2020 13:47]

En dat is dan een van de eerste signalen dat XS4ALL niet langer meer is wat het ooit was.
Precies had dit al verwacht. Nog weekje wachten en dan zit ik bij freedom. Bye bye xs4all
Ik ga binnenkort over (vind switchen van ISP in de 'corona thuiswerktijd' toch een beetje eng).

Dit soort berichten dat er ondanks de belofte 'dat alles hetzelfde zou blijven' er toch features verdwijnen zorgen er wel voor dat ik eens wat haast moet gaan maken met de overstap.

Freedom ondersteunt natuurlijk wel gewoon 2FA.

[Reactie gewijzigd door koen_92 op 15 juli 2020 11:48]

Als founding member ben ik in de tweede batch overgestapt en het is totaal vlekkeloos verlopen. Op de dag van de migratie ging de stekker om een uur of 6 's ochtends om en mijn FritzBox maakte direct met Freedom verbinding.

Sindsdien ook eigenlijk vrijwel vlekkeloos. Ik heb 1 of 2 momenten gehad dat de verbinding verbroken werd, maar dat was na enkele minuten weer opgelost.

Voor een 'beta test' denk ik dat Freedom hard op weg is om kwalitatief een beter product neer te zetten dan KPN/XS4ALL kunnen bieden.
Weet jij tonnert of ik de configuratie van xs4all van de fritzbox gewoon kan downloaden en uploaden op de fritzbox van freedom en dat het dan out of the box werkt?
Sorry voor het verlate antwoord, wellicht heb je het al. Maar dat zou moeten werken, ze hebben beide een identieke config.
Hoi tonnert

Alsnog bedankt voor je reactie. Werkt inderdaad 😊
Hoop stennis om een providerwebmail, waarvan ik mij afvraag waarom het überhaupt nog bestaat.
Ja leuk dat jij het niet gebruikt of het nut niet ziet, maar mensen die bij xs4all zitten gebruiken dat mailadres misschien al 25 jaar, dus dan is het een beetje een afgang om ineens met een hotmailadres aan te komen zetten. Niet alleen een afgang maar ook een achteruitgang, juist op veiligheidsgebied waar dit ook nog eens bij kwam kijken.

Los daarvan: er was beloofd dat er (juist aan de unieke eigenschappen) van xs4all niets zou veranderen. Dan is dit wel een beetje heel snel van KPN om die uitspraak aan het achterwerk te lappen.

[Reactie gewijzigd door mae-t.net op 15 juli 2020 13:30]

Er zou niets veranderen? Het lijkt me sterkt dat het zo gezegd is. Er is geen bedrijf waar niets veranderd, zelfs zonder overname. Al is het alleen al omdat bestaande hardware en software niet het eeuwige leven heeft en vervanging ook afhankelijk is van externe factoren.

Daarbij mag je je ook afvragen of dit een verandering is waar je heel erg teleurgesteld om kan zijn. Wel op webmail 2FA toepassen maar het niet nodig hebben via pop/imap/smtp wat klanten massaal gebruiken doet behoorlijk af aan het doel van 2FA. Daar zit de klant op de hotelkamer via de smarttv zijn mail te controleren door zijn gebruikersnaam en wachtwoord in te tikken met daarbij een otp. De crimineel met malware op de smarttv had alleen de gebruikersnaam en wachtwoord nodig om via smtp spam en virussen te kunnen verzenden?

[Reactie gewijzigd door kodak op 15 juli 2020 14:02]

Toen ik wilde overstappen vroegen ze waarom? Ik gaf aan omdat er veel gaat veranderen bij xs4all en ik daar niet voor gekozen heb. Ze bleven volhouden dat er niks zou veranderen. Nou wel dus en dat snap ik ook want het voor KPN veel efficiënter om van dezelfde infra gebruik te gaan maken. Maar nogmaals daar heb ik niet voor gekozen toen is xs4all koos. Dus ik stap over op freedom.
@hydex hoe is je verhaal hier relevant? Ik lees nergens dat deze wijziging van otp bij webmail iets te maken zou hebben met de fusie. Je grijpt dus een wijziging die daar mogelijk mee te maken kan hebben aan om over te stappen? En is deze wijziging dan inhoudelijk voor jou relevant? Je gebruikte otp-tweestapsverificatie op webmail en de wijziging is voor jou geen verbetering of gaat het je meer om de wijziging ongeacht of het inhoudelijk een verbetering kan zijn? Ik denk dat een discussie als ze veranderen iets en dus ga ik weg weinig meer te maken heeft met dit nieuws als je er geen relatie in kan tonen met je keuze. Dat klinkt meer als algemeen klagen dat een bedrijf je niet bevalt omdat het niet bij een bepaalde verwachting die je over over niet veranderen hebt past.
Ik vind je reacties wel wat kort door de bocht kodak.

Ten eerste is er natuurlijk heel wat vooraf gegaan aan de integratie van XS4ALL bij KPN. Dat ging niet zonder slag of stoot en met veel emotie. XS4ALL was (ja, ik zei was) een unieke provider m.b.t. klantenservice, security, ipv6 en eigen ip adressen om nog maar niet te spreken van hun privacy standpunten.

Als je dan ziet dat er binnen een hele korte tijd al een feature van de webmail verdwijnt (of jij die nu nuttig of veiliger vindt doet even niet ter zake) die als doel had de beveiliging te verhogen voor die webmail dan is het niet gek dat mensen 1 + 1 optellen toch? Ik zit niet bij xs4all, maar als ik het zo lees is het mij volstrekt duidelijk dat xs4all totaal opgenomen wordt in de KPN infra en daar heb je geen 2FA.

Ik denk ook dat het extreem naïef is om te denken dat er ook maar iets van de mentaliteit en de insteek van xs4all overblijft nu. Daar is KPN gewoon het bedrijf niet voor.

En om zo'n verandering dan weg te zetten als "er veranderd iets, dus ik ga weg" vind ik echt wel bijzonder. Helemaal voor de mensen die ooit gekozen hebben voor xs4all zijn security en privacy speerpunten (tenzij ze bewust teveel wilden betalen, dat kan ook).
dan is het niet gek dat mensen 1 + 1 optellen toch?
Het gaat mij er niet om of het gek is dat tweakers zo 1+1 doen, maar of het relevant is bij het bericht. Ik vind het niet vreemd dat er emoties zijn of ook het verleden mee speelt bij het vormen van een mening. Maar in een discussie bij het nieuws verwacht ik dat tweakers die emoties en gedachten over wat er is gebeurt wel wat onder controle hebben en niet te veel laten gelden in plaats van feiten bij dit nieuws. Dat mis ik in een aantal reacties en dan mag je hier ook verwachten dat als er enige relativering komt op die emoties. Zeker als die van het niveau vooringenomenheid lijken te zijn of niet meer helemaal on-topic om een eigen algemenere voorkeur of afkeur te noemen. Daar is gathering voor.
Natuurlijk is er een kansje dat xs4all als zelfstandige businessunit ook zoiets zou hebben gedaan, maar die kans lijkt me klein genoeg om kpn het nadeel van de twijfel te gunnen. Zo niet, dan toch - zelfs de marketingafdeling had dat moeten zien aankomen. Als het echt en oprecht niet zo was, dan had het alsnog overduidelijk moeten zijn dat de klanten die uitleg eraan zouden geven. Ook de klanten die de maatregel niet trof want veel klanten zijn redelijk belezen en kennen het gedicht van Niemoeller.

[Reactie gewijzigd door mae-t.net op 17 juli 2020 01:18]

Er stond in de brief dat wij XS4all klanten niets van de overgang naar KPN zouden merken, dat de service van hetzelfde niveau zou zijn zoals we gewend waren.

Dat dat nu een leugen blijkt, is geen verrassing voor mij.
Er stond in de brief dat wij XS4all klanten niets van de overgang naar KPN zouden merken, dat de service van hetzelfde niveau zou zijn zoals we gewend waren.
Ten eerste lees ik nergens dat deze verandering iets te maken heeft met de overgang naar KPN. De provider bestaat al 25 jaar met tal van veranderingen. Daarnaast lees ik niet wat de betekenis van op hetzelfde niveau blijven is. Ik kan me zo voorstellen dat klanten en de provider daarmee ook verwachten dat de beveiliging op een goed niveau komen of blijven. Misschien is dat laatste met deze 2FA niet het geval geweest omdat het alleen op de webmail zou zitten terwijl je via andere manieren zonder 2FA misschien hetzelfde kon? Het is dus maar net waarom je er een leugen in wil zien.
Ik vind het ook spannend om over te stappen. Maar stel het werkt niet, schat de kans klein in, kan ik nog voor mijn werk evt mijn telefoon als hotspot gebruiken en daarop werken. En anders even de buren lief aankijken of ik van hun internet gebruik mag maken.. Genoeg backup mogelijkheden ;)
Dat lijkt dan op een houtje touwtje oplossing.
Upgraden wil zeggen dat je een oud product vervangt met een nieuwe versie van dat product. Dat er in een nieuwere versie functies weg zijn die er eerst wel waren is niet ongewoon. Meestal worden ze dan vervangen of er is iets anders aan de hand.

Wat bij upgrade wel uit maakt is of het product het zelfde is. En dat lijkt niet zo te zijn. Xs4all lijkt over te stappen van roundcube naar andere open source webmail software. Dat is geen upgrade vanuit de software gezien. Misschien brengt de woordvoering het als een upgrade vanuit het eigen perspectief: de dienst webmail krijgt namelijk een vernieuwing. En ja daar kunnen ook dit soort niet standaard functies die in dit geval mogelijk schijnveiligheid geven verdwijnen. xs4all lijkt al 8 jaar of langer bezig om soms 2fo te promoten maar ik zie niet dat het een standaard dienst is. En een functie die nauwelijks een functie heeft en misschien zo meer kwaad doet dan goed kan dan verdwijnen.
Nou, ja,

Vervanging = replacement
Upgrade = verbeteren

Het schrappen van een beveiligingsoptie (even los van de discussie van effectiviteit van deze optie) bij een replacement is dan een 'downgrade' m.b.t. de beveiliging bij de 'product replacement'.

Maar goed, je kan er veel kanten mee op. Desalniettemin vindt ik het slecht als de marketingpraatjes iets een upgrade bestempelen in plaats van een vervanging door een product waarbij een beveiligingsoptie zal verdwijnen. Leg het dan goed uit.
Als een bedrijf de introductie van een functie en het uitfaseren van die functie niet heel uitgebreid aan bod laat komen en zelfs alleen aan bepaalde klanten richt dan betwijfel ik of het veel waarde hecht aan een mogelijk item op een nieuwsplatform. Dan kunnen wij hier wel een discussie voeren over de betekenis van een bepaald woord als upgrade en klagen dat het bedrijf het niet goed zou uitleggen, maar ik denk niet dat het bedrijf daar erg mee zit. Ik betwijfel zelfs of de klanten die wel van de otp gebruik maakte er echt mee zitten als ik niet eens kan zien wat hun achtergrond en motivatie is om deze functie op webmail te gebruiken terwijl de effectiviteit misschien niet duidelijk is.
Ik ben het met je eens dat KPN er in het geheel niet mee zit om gedane beloften t.a.v. XS4All geen stand te doen houden.

In dat licht vindt ik het item wel enige nieuwswaarde hebben op een site als Tweakers. En als er dan discussie wordt gevoerd over de (flauwe, onduidelijke, onjuiste, verbloemende, verkeerde of wat dan ook) formulering die in het bericht door KPN wordt gebruikt dan vind ik dat vooral goed.
Je denkt te veel voor anderen.
Feit is, een functie die beoogt gebruik op een openbare computer wat minder onveilig te maken gaat vervallen. De afweging tussen de belangen van de provider en haar gebruikers is hier duidelijk niet in het voordeel van de laatsten.
De afweging tussen de belangen van de provider en haar gebruikers is hier duidelijk niet in het voordeel van de laatsten.
Omdat iets vervalt wil het nog niet zeggen dat dat slecht is. Bij een verhuizing vervalt meestal een oud slot. Is dat erg? Nee, je gebruikt een ander slot. Maar deur nummer 5 had eerst 2 sloten en nu nog maar 1, is dat dan slecht? Alle andere deuren hadden geen extra slot en daar kon je met dezelfde sleutel als bij deur nummer 5 naar binnen, zelfs als je de sleutel van het extra slot niet had.
Zal het extra slot handig zijn als je last hebt van domme criminelen die alleen deur 5 proberen of denken dat alle deuren dus een extra slot hebben? Dat zal best. Maar beveiliging is meer dan dat. Het extra slot kost bijvoorbeeld een investering (bijvoorbeeld in geld en tijd voor het laten werken van het slot, uitleg en promotie, de helpdesk) en bijna niemand leek het te gebruiken. Dat zijn ook belangen van de klant en dat is niet perse in het nadeel als ze op 1 deur 1 extra slot missen dat verder nergens helpt als hun gegevens op een openbare computer lekken.
Noemen ze ook wel downgrade.

Maar dat is marketingtechnisch niet zo goed te verkopen als je claimt de kwaliteit van XS4All te behouden na het volledig inlijven in KPN.

Imho een gevalletje #Fail
Inderdaad, dit is een downgrade...txt aanpassen?
Waarschijnlijk kan het systeem van KPN het niet, en nu ze de boel samenvoegen gaat deze feature kapot.
XS4all bestaat niet meer. De dienstverlening wordt of is al bijna standaard KPN en die hebben geen 2FA op hun web mail.
Geen xs4all klant, maar hebben ze dan helemaal geen optie meer voor tweestap verificatie?
Dat is dan niet echt een veiligheid vooruitgang.
Ik zie OTP niet het zelfde als tweestap, of zie ik dat verkeerd? Althans, het is wel tweestaps, maar meer als een tijdelijke wachtwoord dan een extra code om je inlog te bevestignen

[Reactie gewijzigd door Christoxz op 15 juli 2020 10:39]

Ik zie OTP niet het zelfde als tweestap, of zie ik dat verkeerd?
OTP is een factor, waarmee je bewijst dat je iets hebt (dat OTP's kan genereren). In dit geval wordt deze gecombineerd met een wachtwoord, wat ook een factor is. Daarmee bewijs je dat je iets weet. Twee factoren = twee stappen.

[Reactie gewijzigd door The Zep Man op 15 juli 2020 10:59]

De OTP komt uit een andere bron, gelinked aan de gebruiker, dus niet uit het geheugen (of password manager) van een user. Dat is dus de 2e factor.
Slechte zaak. Wat volgens mij helpt is om een e-mail alias te gebruiken, zodat het e-mail adres niet de gebruikersnaam is maar iets anders. Volgens mij ook redelijk veilig.
Dat is security through obscurity. Dat is absoluut geen goed uitgangspunt om dingen secure te houden.
Pas op, obscurity is niet per definitie verkeerd.
Deze uitspraak gaat alleen over het ontwerp van applicaties.
Ik ben een groot aanhanger van de gedachte er achter, maar het wordt vaak verkeerd uitgelegd.

Een simpel tegenvoorbeeld is een wachtwoord. Wachtwoord zijn ook geheim. Dat noemt niemand "security through obscurity".

Obscurity kan wel degelijk iets toevoegen, zelfs als die obscurity niet perfect. Je moet er alleen niet op vertrouwen en soms kun je meer voordeel halen uit het laten zien van je werk zodat anderen je kunnen helpen dan van geheim houden waar de fouten zien.
Je zegt obscurity, maar het zal niet altijd makkelijk zijn om een verband te vinden tussen gebruikte adressen dus daar zit wel degelijk een graad van beveiliging in. Een adres+wachtwoord dat uitlekt compromitteert effectief dus maar 1 account en niet alle accounts van een gebruiker.
Nee hoor, aan de dienstverlening van XS4ALL gaat niets veranderen wanneer het opgaat in KPN.
Aan de andere kant... wie gebruikt er überhaupt nog (web)mail van zijn provider?
Ik. Naast google. Nadeel van gmail en de concurrenten is dat deze de mail mee lezen/scannen.
Dit staat duidelijk in de voorwaarden. Bij mail van een Nederlandse ISP heb je dat niet.
Wellicht een optie om Protonmail of Tutanota te overwegen. Die lezen ook niet mee en slaan je email versleuteld op.

Uiteindelijk is de keuze een kwestie van vertrouwen, van die diensten en van je provider. En van behoud van emailadres bij overstappen van provider.
+1Anoniem: 951889
@ChillinR15 juli 2020 11:38
Waarom word dit zo veel op 0 gemod? Het lijkt me toch waardevol in een discussie rondom email, om providers te noemen die wél veilig (lijken te) zijn. Het zijn dan wel geen ISP's maar niemand verplicht je om de email van je ISP te gebruiken. Sterker nog ik raad het af, omdat je dan niet vrij van ISP kan wisselen zonder overal je email adres te moeten wijzigen en al je contacten op de hoogte te stellen... wat een gedoe. ISP mail is een blok aan je been.
Soverin verdient ook wel een vermelding in je lijstje imo :)
Ah, die kende ik nog niet. Leuk idee qua eenvoud en toegankelijkheid om te focussen op email en daar een domeinnaam bij te geven, in plaats van het omgekeerde zoals veel hostingbedrijven doen.

Helaas hebben ze het nergens over encryptie en kan je blijkbaar met je telefoonnummer een reset van je wachtwoord krijgen. Diensten als Tutanota en Protonmail focussen juist op de encryptie, en dat vind ik persoonlijk belangrijk. Ze bieden ook beide een relatief gebruiksvriendelijke manier om versleutelde emails naar anderen te sturen (al gebruik ik dat in de praktijk nauwelijks).
Soverin is ook de provider die voor Freedom de maildienst levert.
Wat @Boss waarschijnlijk bedoelt is niet zozeer of je webmail gebruikt in plaats van een mailclient, maar of je Z80@kpnplanet.nl gebruikt in plaats van info@Z80.nl

Al je contacten hebben dan ineens een emailadres wat niet meer werkt als je weggaat bij KPN of je krijgt gedoe als ze die domeinnaam willen ‘uitfaseren’ zoals dat dan zo mooi heet.
Ligt een beetje aan de definitie. Google 'leest mee' met software die patroonherkenning doet voor marketing doeleinden.

Bijvoorbeeld spamassassin (kan in ieder geval een aantal ips's aanwijzen die dat gebruiken) is software en die 'leest mee' met patroonherkenning voir spam detectie.

Het enige verschil is eigenlijk het doel, niet het 'meelezen'.
Ja en nee. Je gaat ervan uit dat Google uitsluitend meeleest met patroonherkenning voor marketing, maar dat staat nergens bij mijn weten, en bovendien is dat ook al een datalek in de ogen van een wat serieuzere gebruiker zelfs indien niet in de ogn van de wet. En je weet niet hoe diepgravend en de garantie gaat voor zover je de server met eigen ogen kunt zien. Bij een volledig Nederlandse provider is de transparantie doorgaans een stukke beter.
Ook Google moet in Europa voldoen aan de eisen van de AVG (en in NL aan de Uitvoeringswet AVG).
Dat staat los van de vraag of je Google vertrouwd.
Ik werk zelf in de consumenten elektronica en ik kan je vertellen uit ervaring met klanten: Een hele hoop gebruiken dit! Daarnaast zijn er een hoop klanten die zichzelf al buiten weten te sluiten door nergens hun wachtwoord te hebben staan, laat staan dat ze overweg kunnen met iets als 2FA en die ergens kunnen ontvangen om weer verder te kunnen. Dus het weglaten van deze functie zal voor veel van mijn klanten juist helpen, evenals de tijd die ik erin moet steken om ze weer verder te helpen! :+
LOL Ik geloof je meteen, maar XS4ALL was nou juist de provider voor tweakers, niet voor de digibeet die al moeite heeft met knippen en plakken.

Het lijkt mij een drama als ik elke keer een (tweede) wachtwoord moet overtypen via een random reader of zo, alleen om bij m’n mail te komen, maar als daar behoefte aan is..
Met veel 2FA-implementaties kun je aangeven dat je na de eerste keer inloggen met een OTP het ‘apparaat vertrouwd’. Dan heb je het een volgende keer niet meer nodig en kun je alleen met je normale credentials inloggen.

Ik ken ook implementaties waarbij het ‘vertrouwen van apparaat’ voor een bepaalde tijd geldt. Een maand bijvoorbeeld.
Interessant, al wordt daarmee natuurlijk ook een deel van de beveiliging teniet gedaan.
De meeste aanvallen worden juist via "vreemde" devices gedaan en dan zou 2FA nog steeds noodzakelijk zijn.

Maar een klein gedeelte kan hiermee inderdaad ongedaan gemaakt mee worden.
Moah, gewoon copy-pasten uit een browser extention:
https://github.com/Authenticator-Extension/Authenticator
Gebruikers een functie ontzeggen als bescherming tegen hen zelf is pedant.
Daarom leg ik ook uit wat de functies inhouden met de voor/nadelen. Keuze bij de klant zelf leggen en ze begeleiden in deze keuze is mijn voorkeur van aanpak. Graag leer ik mijn klanten deze dingen ipv de keuze voor hun te maken. Al merk ik dus wel als de keuze, zoals deze situatie, 'gebruikersgemak' (1 wachtwoord) tegenover 'veiligheid' (1 wachtwoord + een 2FA optie) er erg veel klanten kiezen voor de gebruikersgemak-optie.
Steeds minder mensen. Maar juist bij XS4ALL, een van de oudste providers, relatief veel.
Gebruik het altijd voor registraties e.d. van dingen die niet zo belangrijk zijn. Mocht ik ooit van provider overstappen dan is er geen man overboord als ik het e-mailadres kwijtraak.
De provider zelf _/-\o_
Ik vermoed dat het samenvoegen van het e-mailplatform Xs4all en KPN hieraan grondslag heeft. Ze zullen alles verhuizen naar het systeem van KPN waar otp geen mogelijkheid is.

Aan de andere kant; wie gebruikt er nou nog een e-mailadres van zijn ISP? Uiteindelijk is dat nooit een goed idee.
Dat denk ik ook. KPN heeft alle andere voormalig zelfstandige provider email adressen al jaren samengevoegd op een groot centraal email platform. Dat platform heeft geen OTP features dus laten ze die feature gewoon vervallen. De CEO die ons beloofde dat er "niets veranderd voor XS4ALL klanten" is alweer een tijdje weg, dus de afbraak van XS4ALL kan gewoon doorgaan.
Er kunnen veel meer redenen zijn om een bepaalde feature te laten vallen. Bijvoorbeeld omdat het geen standaard vorm van inloggen bij xs4all is. Of omdat het misschien schijnveiligheid is als het alleen op de webmail zit terwijl het bij andere inlogvormen van xs4all niet nodig is. Of omdat klanten het om deze redenen nauwelijks gebruiken.
Dat kunnen inderdaad ook geldige redenen zijn, maar die dat het generieke mailplatform geen 2FA ondersteund weet ik vrij zeker omdat ik daar een tijdje rondgelopen heb. Mogelijk dat mijn kennis verouderd is, maar ik vrees van niet.
Je moet eens weten hoe vaak ik hier op het werk nog @planet.nl, @hetnet.nl, @home.nl, @casema.nl (Laatst zelfs nog een @12move.nl adres, nostalgie!) tegen kom. Veel mensen gebruiken het nog steeds omdat het simpelweg "makkelijk is en ze die krijgen".
Dat die e-mail adressen nog bestaan zegt niks over het onderliggende e-mail platform en de software die daar op draait. Het ziet er gewoon naar uit dat de xs4all.nl adressen gemigreerd worden naar hetzelfde platform als alle andere kpn adressen.
Dat klopt, maar de poster vroeg zich af of en nog wel zo veel mensen zijn die het adres van een ISP gebruiken. Daarop mijn antwoordt dat dit nog best vaak voor komt :)
(...)
Aan de andere kant; wie gebruikt er nou nog een e-mailadres van zijn ISP? Uiteindelijk is dat nooit een goed idee.
Mwah... ik heb al een eeuwigheid een @dds.nl-adres, en nog steeds in gebruik. Ik geef toe, het is niet (meer) mijn primaire adres maar ik ben ook niet van plan dat op te zeggen. Nu is DDS nooit mijn provider geweest, maar ik heb dat adres al zolang dat ik 5 karakters voor de apenstaart heb.

Je moet niet vergeten dat (back in the day) je nog een beetje geluk kon hebben met een redelijk 'mooi' en kort mailadres, waar je tegenwoordig aan minimaal 12 karaters vastzit, en je in zat gevallen niet ontkomt aan een telling omdat je niet de enige Jan Janssen bent die een gmail-account wil gebruiken.

Dat alles gezegd hebbende: mijn primaire adres staat inderdaad gewoon op een eigen domein ;)
Je hoeft het xs4all-e-mailadres niet te gebruiken om hun imap server te kunen gebruiken. Ik stuur eenvoudig alle e-mail voor mijn domein door, en lees ze via imap.
Mocht ik ooit weggaan bij xs4all dan kopieer ik simpelweg alle e-mail op de imap-server naar een andere imap-server.
Xs4all lijkt al enige tijd bezig te zijn om over te stappen van Roundcube naar OX App Suite. Of dat met KPN te maken heeft betwijfel ik. OX App Suite is open source, richt zich op open source systemen zoals linux distributies voor de servers, apache en mariadb. Dat is niet waar KPN erg om bekend staat.

Ik kan me voorstellen dat het meer gaat om bedrijfszekerheid. OX App Suite lijkt veel meer support te hebben voor bedrijven net zoals er ooit verschillen waren in professionele support voor linux disctributies. Ook lijkt roundcube alleen geschikt voor mail terwijl de wereld inmiddels gewend is om ook contactgegevens en agendafuncties voor mobiel gebruik mee te kunnen nemen.
XS4ALL biedt geen CALDAV en CARDDAV. Soverin (wat Freedom gebruikt) biedt die services voor agenda's en adresboeken wel. Heeft mij altijd verbaasd dat XS4ALL deze diensten niet heeft geïmplementeerd.
Ik zou het verwijderen van een security mechanisme geen upgrade willen noemen. Een update zou nog kunnen, maar een upgrade is het zeker niet.
Insert discussie.... er gaat niets veranderen...
Bizar dat door een "upgrade" een essentiële functie zoals tweestapsverificatie niet meer werkt... Nog erger dat er niet eens een alternatief voor komt. 8)7
"Door een upgrade van ons e-mailplatform bieden wij deze inlogmethode vanaf dan niet meer aan" Ik zou zelf de term "upgrade" achterwege laten bij het aankondigen van dit soort nieuws. Noem het dan "verandering" :)

Als bijna niemand het gebruikt dan zou je je beter kunnen afvragen waarom dat is, en daar vervolgens wat aan doen. Zelf stel ik het overal in waar het maar kan. Ik gebruik andOTP en sla de database af en toe encrypted op zodat ik geen problemen krijg als mn telefoon kapot gaat.

[Reactie gewijzigd door teek2 op 15 juli 2020 10:41]

Op dit item kan niet meer gereageerd worden.


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True