Aantal berichten verloren

René

Moderator
Berichten
9.836
Internet
  1. KPN
Helaas hebben we gister (17-01-2023) aan het einde van de dag een backup moeten terugzetten.
Hierdoor zijn de berichten van de afgelopen 24 uur verloren gegaan.

Achtergrond:
De laatste tijd wordt er door diverse bots geprobeerd in te loggen op oude inactieve accounts op diverse sites, waaronder dit forum.
Helaas met succes, omdat er nog steeds gebruikers zijn die overal hetzelfde wachtwoord gebruiken.
Is zo'n wachtwoord eenmaal ergens gelekt, bijvoorbeeld via een slecht beveiligde webshop, dan kan een aanvaller met dat account overal inloggen.

Om dat te voorkomen wilde we preventief de wachtwoorden op dit forum resetten, met name voor de inactieve accounts.
Tijdens dat resetten ging er iets mis met de database waardoor vrijwel alle accounts werden verwijderd.
Wel veilig, maar niet erg handig. Enige optie was om alles weer terug te zetten, en dat is gelukkig goed gegaan.
 
Dus eigenlijk heb je het zelf veroorzaakt? Wat betreft die wachtwoord kluizen, het hele debable met lastpass toont wel aan dat die methode ook niet bepaald 100% veilig is.

Als je om wat voor reden dan ook malware op de computer krijgt, en we weten allemaal dat kan al door een zero-day en je hebt een wachtwoord kluis open staan die gejat wordt met de hele inhoud weten ze ook echt meteen alles. Dat is misschien nog wel gevaarlijker dan 1 wachtwoord wat ergens uitlekt en op meerdere sites wordt hergebruikt.

Ik zou aanraden ouderwets bepaalde wachtwoorden op te schrijven en dat op een veilige plek te bewaren. Ja dat kan ook gejat worden of ingezien maar dan moet iemand eerst fysieke toegang hebben.

En twee-factor authenticatie kan, alleen dat is bloed irritant en bovendien beschermd het niet tegen zoiets simpels als een session-cookie jatten.
 
(bericht iets genuanceerd)
Er worden wel meerdere backups gemaakt per dag, maar het ligt allemaal wat complexer waardoor we naar een eerdere backup moesten teruggrijpen.

Doordat we een password reset op de meeste accounts hadden geforceerd, kregen al die accounts de status 'inactive'. Ze blijven dan inactive totdat de gebruiker probeerd in te loggen, een mail ontvangt en dan het wachtwoord reset.
Dat was rond 09:00 uur 's ochtends.
Dat is verder geen probleem, alleen loopt er om de zoveel tijd een automatisch maintenance script dat alle accounts met status 'inactive' opruimd. En dat was in dit geval natuurlijk niet de bedoeling. Gedurende de dag verdwenen er dus opeens heel veel accounts.
Daarom moesten we terug naar een backup van voor 09:00.
 
Laatst bewerkt:
Dus eigenlijk heb je het zelf veroorzaakt?
Uiteraard! :)
Maar ik dacht eerst aan corruptie in de database omdat er na het uitvoeren van een batch reset password opeens accounts weg waren.
Dat bleek later te komen door een andere maintenance job die altijd al actief was, maar nu werd getrigged.
Gelukkig wel allemaal te verklaren en zoals 99% van alle storingen veroorzaakt door menselijke interactie.

Wat betreft die wachtwoord kluizen, het hele debable met lastpass toont wel aan dat die methode ook niet bepaald 100% veilig is.
Hier zullen we het nooit over eens worden, maar dat ben ik totaal niet met je eens.
Geen 1 methode is 100% veilig. En wat er met Lastpass is gebeurd helpt daar niet bij, maar dat de er kluizen van gebruikers zijn gelekt wil niet zeggen dat er wachtwoorden zijn gelekt.
Elke wachtwoordkluis wordt zwaar ge-encrypt met een aantal variablen, waaronder het persoonlijke wachtwoord. Dat is niet zomaar even te ontcijferen.

Het beste is dan misschien om zelf je kluis te beheren op je eigen hardware, maar dat is dan een afweging tussen gebruikersgemak en risico.

Er zijn natuurlijk voor en nadelen, maar ik kies er toch echt voor om voor elke site een uniek wachtwoord te generen van 20+ karakters en dat centraal op te slaan, zodat ik er onderweg ook bij kan.
Invullen gaat dan ook met 1 klik. Ik moet er niet aan denken om al mijn unieke wachtwoorden op te schrijven op papier.
 
(bericht iets genuanceerd)
Er worden wel meerdere backups gemaakt per dag, maar het ligt allemaal wat complexer waardoor we naar een eerdere backup moesten teruggrijpen.
Dank voor de uitleg. Dit is altijd leerzaam. Het gaat vaker mis met scripts

Atlassian: fout met uitvoeren script veroorzaakte storing bij honderden klanten

En deze is nog erger omdat dit fout ging bij het backup script. Plus goede uitleg waardoor het mis ging.

Japanse universiteit verliest 77 terabyte aan data door fout in back-upscript
 
Terug
Bovenaan