Waarschuwing: Synthforum gehackt

Misschien kunnen jullie in vervolg de priveberichten in ieder geval na bijvoorbeeld 1 maand nuken. Je krijgt ze immers toch ook in de mail. Het heeft weinig zin om deze langer vast te houden.
 
Wat voor stiekeme zaken worden hier gedaan, waardoor berichten versleuteld moeten worden?
 
Versleutelen van pb's heeft niet zoveel zin omdat je de sleutels ook in de database zou moeten opslaan als je wil dat de ontvanger de pbs nog kan lezen.
Toch zou het in principe wel kunnen. Te denken valt aan asymmetrische encryptie, met een public key worden pb's versleuteld en aan de hand van het wachtwoord een versleutelde private key decrypten zodat de ontvanger het kan lezen na het inloggen. Dus de database bevat van elke gebruiker een public key en een versleutelde private key.

Wat voor stiekeme zaken worden hier gedaan, waardoor berichten versleuteld moeten worden?
Het gaat erom dat een hacker het niet kan lezen als die succesvol binnendringt.
 
Toch zou het in principe wel kunnen. Te denken valt aan asymmetrische encryptie, met een public key worden pb's versleuteld en aan de hand van het wachtwoord een versleutelde private key decrypten zodat de ontvanger het kan lezen na het inloggen. Dus de database bevat van elke gebruiker een public key en een versleutelde private key.

Zou het niet nuttiger zijn om adressen in een separaat versleuteld database veld op te slaan, en de rechten voor het ontsleutelen van dat veld zo in te stellen dat enkel de oorspronkelijke gebruiker en zijn (actieve) contacten erbij kunnen? Je zou het zelfs zo kunnen doen dat de oorspronkelijke gebruiker expliciet toestemming moet geven voordat iemand zijn adres kan lezen, bv. d.m.v. het aanvinken van een bepaalde optie in het PM scherm, waarna het adres voor een beperkte periode toegankelijk is voor de andere gebruiker. Dan kan je in principe de versleuteling redelijk simpel houden.

En wat betreft een 100% veilige website: Dat kan natuurlijk in principe als de plek waar de website is opgeslagen read-only is (even hardware firmware-hacks en DDOS aanvallen e.d. buiten beschouwing latend). Alleen heb je daar niet zo veel aan als je een interactieve website wilt...
 
Wat voor stiekeme zaken worden hier gedaan, waardoor berichten versleuteld moeten worden?

Ze zijn bang dat persoonlijke info op internet komt.

Gewoon kik/telegram gebruiken dus bij dat soort info.

Verder kan ik mij niet voorstellen dat pb’s versleutelen makkelijk is. Laat staan dat de makers van het forum type wat hier gebruikt wordt dat hebben geïmplementeerd. Al is dat een aanname natuurlijk.

Maar sommige mensen vergeten dat als iets kan, het ook nog gemaakt moet worden. Dat kan heel pittig zijn. Niet altijd maar vaak wel.

Anyway ben je bang. kik/telegram gebruiken.
 
Nu heb ik geprobeerd het wachtwoord aan te passen, maar kan ik die instelling niet bewaren, want ik krijg de melding “Email addresses must match”?
 
Nu heb ik geprobeerd het wachtwoord aan te passen, maar kan ik die instelling niet bewaren, want ik krijg de melding “Email addresses must match”?

Je moet in beide velden het juiste e-mail adres invullen. Dan komt het goed.
 
Waarom zou er geen software ontwikkeld kunnen worden, waar geen fouten inzitten en geen exploits mogelijk zijn?
Mijn vermoeden is dat veel software te vroeg op de markt wordt gebracht en dat de klant als testpanel mag functioneren.



Waarom zijn die er toch altijd wel?

Maar misschien geraak ik off-topic.. :-)

Het is onmogelijk om geen fouten te maken in code. Je kan fouten er uit halen door bv testen. Maar je kan nooit een 100% dekking krijgen bij testen (exponentiële groei aantal tests bij hogere dekking). Kosten spelen daar vooral een rol.

Daarnaast kan je je niet 100% beveiligen tegen innovatie. Methodes die er nog niet zijn kan je je niet 100% tegen beveiligen.
 
Zou het niet nuttiger zijn om adressen in een separaat versleuteld database veld op te slaan, en de rechten voor het ontsleutelen van dat veld zo in te stellen dat enkel de oorspronkelijke gebruiker en zijn (actieve) contacten erbij kunnen? Je zou het zelfs zo kunnen doen dat de oorspronkelijke gebruiker expliciet toestemming moet geven voordat iemand zijn adres kan lezen, bv. d.m.v. het aanvinken van een bepaalde optie in het PM scherm, waarna het adres voor een beperkte periode toegankelijk is voor de andere gebruiker. Dan kan je in principe de versleuteling redelijk simpel houden.
En wat betreft een 100% veilige website: Dat kan natuurlijk in principe als de plek waar de website is opgeslagen read-only is (even hardware firmware-hacks en DDOS aanvallen e.d. buiten beschouwing latend). Alleen heb je daar niet zo veel aan als je een interactieve website wilt...

Ik kan jullie wel volgen met betrekking tot het het veiliger maken van de privé berichten, echter weet dat we met standaardsoftware werken, ttz. je gaat geen aanpassingen doen aan een product dat je zelf niet bouwt. Aanpassingen doen is theoretisch mogelijk maar dan kan je de forum software niet meer zo maar upgraden (wat dus ook niet wenselijk is).

Het vervelende aan deze hele zaak is dat vbulletin ook maar enkel patches had voorzien voor de 5.5 en niet voor de 5.4 , wat ons dwong om de forum software ongetest up te graden EN de onderliggende server software (PHP) ook moest worden geüpgrade (naar PHP 7.1) omdat dit de versie is die 5.5 enkel wordt ondersteund. Stel nu voor dat je nog je maatwerkcode dient te injecteren....
 
vB5 password is hashed via javascript before it is submitted using the function md5hash(). You can get the hash by opening the devtools and looking at the post submission in the network tab. This is to prevent plain text password transfers over the network. Modifying your old application to use this same md5hash function should help with synchronizing your passwords.

Dus MD5, wat eigenlijk een veel te snel algorithme is (dus via brute force hackbaar). Zestien jaar jouw paswoord houden is nooit een goed idee.
 
Het is onmogelijk om geen fouten te maken in code. Je kan fouten er uit halen door bv testen. Maar je kan nooit een 100% dekking krijgen bij testen (exponentiële groei aantal tests bij hogere dekking). Kosten spelen daar vooral een rol.

Daarnaast kan je je niet 100% beveiligen tegen innovatie. Methodes die er nog niet zijn kan je je niet 100% tegen beveiligen.

Dat is een uitleg die ik vaker hoor, maar het gaat er bij mij niet helemaal in. Je kunt toch een volmaakt product ontwikkelen? En zo goedkoop zijn de licenties ook niet.. Waarom kan er geen software ontwikkeld worden die onfeilbaar en onhackbaar is?

Ik denk dat het een keuze is om de klant op te zadelen met een product dat steeds weer "terug naar de reparateur" moet..
 
Dat is een uitleg die ik vaker hoor, maar het gaat er bij mij niet helemaal in. Je kunt toch een volmaakt product ontwikkelen? En zo goedkoop zijn de licenties ook niet.. Waarom kan er geen software ontwikkeld worden die onfeilbaar en onhackbaar is?

Ik denk dat het een keuze is om de klant op te zadelen met een product dat steeds weer "terug naar de reparateur" moet..

Als het inderdaad een keuze zou zijn, dan zou het product ook volmaakt zijn.
 
Waarom kan er geen software ontwikkeld worden die onfeilbaar en onhackbaar is?
Het is mensenwerk en mensen zijn niet onfeilbaar. Kun je niet verwachten dat mensen iets maken dat wel onfeilbaar is. En het gaat trouwens niet alleen om software, er sluipen ook fouten in bv. processors, wat soms pas na jaren aan het licht komt.
 
En zelfs als er geen processors in zitten, kunnen er fouten zijn. In de opvolger wordt dat probleem dan wellicht opgelost, etcetera.
 
Back
Top