Userbase

Na inloggen op de crm => my packages. Na controle bleek in de source gewoon het paswoord van mijn login gegevens te staan in plain text!

Onbegrijpelijk dat dommel hiervoor geen codering toepast. Ook in de URL van de pop-up (bij info van uw adsl pakket) staat gewoon het paswoord in de vorm van:
password=.....

Enkele weken geleden heb ik hier dommel van op de hoogte gebracht. Tijdje later werd mijn ticket gesloten met de mededeling: "we hebben u proberen te contacteren, maar konden u niet bereiken" => Ticket closed!

4 weken geleden dan opnieuw ticket aangemaakt, na tijdje: "we hebben u proberen te contacteren, maar konden u niet bereiken" => Ticket closed! Dit terwijl thuis of op gsm geen oproep heeft plaats gevonden.

Ik vroeg mij af wat jullie als dommelklant ervan vinden dat uw paswoord gewoon uitleesbaar is uit de broncode of url?

Is altijd al zo geweest, leuk eh

.

Natuurlijk zie je wel enkel je eigen wachtwoord als je in CRM ingelogd bent, maar inderdaad; de mensen van Dommel zélf kunnen ook jouw wachtwoord in plain text lezen!

Uit nieuwsgierigheid eens nagekeken en ge hebt groot gelijk. Zowel het paswoord om in te loggen in CRM als mijn adsl login gegevens zijn uit te lezen uit de pagina source.

Bij belgacom is het een bug in de modem, bij dommel is het een achterlijke programmeur. Wie is de volgende?

Ik twijfel ten sterkste dat Dommel de code voor hun eigen CRM systeem geschreven heeft. Dus de slechte programmeur zal waarschijnlijk niet bij Dommel zitten. Echter zijn er veel sites die (spijtig genoeg) nog altijd het wachtwoord van een gebruiker in clear tekst doorsturen. Hou er rekening mee dat het niet is omdat je gegevens niet zichtbaar zijn in de URL, dat ze niet in clear tekst doorgestuurd worden. Het zou allemaal beter zijn indien ze werkten met een MD5 Hash van het wachtwoord dat ze zouden doorsturen (alhoewel dat ook niet zo veilig meer is, aangezien men een collision kan vinden voor een MD5 Hash in enkele minuten).

MAAR. Voor zover ik weet maakt Dommel nog altijd gebruik van HTTPS. Dit betekent dus dat gegevens geëncrypteerd worden. Iemand die zit te packet sniffen op je netwerk/verbinding zal hier dus niet veel wijzer van worden. De enige manier waarop dit je dus problemen kan opleveren is als iemand over je schouder staat mee te kijken met een stuk papier&pen/een goed geheugen. En op dat punt kan je je al evenzeer zorgen beginnen maken of ze niet op je keyboard aant kijken zijn als je je wachtwoord ingeeft. Of een keylogger geinstalleerd hebben terwijl je even naar het toilet was.

Ik ben het niet zeker maar kan je geen SQL injectie doen bij een https verbinding?

dus gewoon een query schrijven waarmee je het wachtwoord uit hun database haalt?

FunkStar schreef:Ik ben het niet zeker maar kan je geen SQL injectie doen bij een https verbinding?

dus gewoon een query schrijven waarmee je het wachtwoord uit hun database haalt?

Hangt ervan af of ze aan user data validation doen of niet... Toch wel een must voor elke dynamische website (en ene die nogal veel programmeertijd kost).

foxhound schreef:Ik twijfel ten sterkste dat Dommel de code voor hun eigen CRM systeem geschreven heeft. Dus de slechte programmeur zal waarschijnlijk niet bij Dommel zitten.

Ik dacht dat de CRM een sterk verouderde en aangepaste versie van ModernBill was.

meon schreef:Ik dacht dat de CRM een sterk verouderde en aangepaste versie van ModernBill was.

Dat valt uit de broncode uit te lezen.

Code: Selecteer alles

         <!-- ModernBill TM .:. Client Billing System .:. Version schedom crm TM .:. schedom crm system .:. version 1.0 -->
         <!-- Copyright © 2001,2002 .:. ModernGigabyte, LLC .:. All Rights Reserved. -->

Anyways omdat ze HTTPS gebruiken maakt het dus helemaal niet zoveel uit dat ze GET in plaats van POST gebruiken bij hun inlogformuliertje, tenzij je natuurlijk iemand over je schouder hebt kijken.

FunkStar schreef:Ik ben het niet zeker maar kan je geen SQL injectie doen bij een https verbinding?

SQL Injectie staat volledig los van het gebruik van HTTPS of niet. Is bij beide mogelijk

foxhound schreef:Anyways omdat ze HTTPS gebruiken maakt het dus helemaal niet zoveel uit dat ze GET in plaats van POST gebruiken bij hun inlogformuliertje, tenzij je natuurlijk iemand over je schouder hebt kijken.

Ja, maar het wordt helemaal leuk: bij elke mail over een factuur, wordt uw paswoord gewoon in de mail gezet en we weten allemaal hoe veilig dát protocol is...

Tijd om mijn wachtwoord aan te passen...

Dat heeft me ENORM gestoord bij Dommel. Elke mail die ik aankreeg, bevatte ook mijn paswoord. Elke keer ik een site tegenkom die dat doet, krijg ik een extra grijs haar. Hoe moeilijk is het om ten minste een MD5-hash te doen? Ok, het is kraakbaar, maar da's nog altijd beter dan helemaal niks...

Het ergste van al is dat 'professionele' web development bedrijven zich daar nogal eens niks van aan trekken. Heb een tijdje gewerkt bij eentje, waar je zo los SQL-injecties kon doen, en erger nog, HTML/Script-injecties. Hun input werd in de verste verte niet gekuist. Daar bovenop kwam dan nog eens dat de paswoorden ook als plain text in de database staken. Had daar eens op gewezen, met duidelijke voorbeelden van wat er allemaal mis kan gaan (tot cross-server Flash injecties toe). Hun reactie: "Jaja, we weten dat." Er iets aan doen... ho maar. 'k Denk dat er veel van die 'professionele' web development bedrijven geeneens weten hoe je sanity checks, algemene user data validation en encryptering moet doen (ook al is aan dat alles helemaal niks aan...)

Als je dan als Dommel een product van zo'n bedrijf koopt, zitten al je klanten idd. mooi met hun paswoord open en bloot.

Jullie zijn ook een zooitje noobs.....in Firefox Show-my-password laat het elke keer zien...

Ongelooflijk....hoe dacht je anders dat het verzonden werd?

Heeft niks met Dommel te maken.

Het is gewoon een Cookie

BasMSI schreef:Jullie zijn ook een zooitje noobs...

enkel hollanders hebben zoveel respect.

BasMSI schreef:Jullie zijn ook een zooitje noobs.....in Firefox Show-my-password laat het elke keer zien...

Ongelooflijk....hoe dacht je anders dat het verzonden werd?

Heeft niks met Dommel te maken.

Het is gewoon een Cookie

Als je niet weet waarover je praat, hou je ten eerste best je mond en ga je ten tweede zéker niet arrogant liggen doen.

Maar goed, als jij denkt het beter te weten: jij mag een applicatie op "Dommel-wijze" schrijven (lees: het paswoord in de URL, zonder SSL) en ik zal op mijn manier een toepassing schrijven. We zullen beiden over eenzelfde hub gaan met ons verkeer (om het niet te moeilijk te maken op netwerk-niveau) en dan gaan we eens kijken wie het eerst de login-gegevens kan achterhalen. Ik wil zelfs grof geld inzetten...

cloink schreef: en dan gaan we eens kijken wie het eerst de login-gegevens kan achterhalen. Ik wil zelfs grof geld inzetten...

Waneer en waar is de catch

Is ook niet moeilijk: het pass opslaan als md5 hash en dan ook versturen als md5 hash om te controleren of het klopt...

Ik vroeg het me ook af waarom die paswoord altijd meeverzonden moet worden?
er zijn genoeg alternatieven ...

Goztow schreef:Is ook niet moeilijk: het pass opslaan als md5 hash en dan ook versturen als md5 hash om te controleren of het klopt...

Yup, en als je er dan een max. aantal logins binnen een bepaalde tijd bij op zet, kunnen mensen geen scripts runnen die paswoords genereren totdat er eentje klopt. Met die twee tesamen zit je al voor't overgrote deel veilig. Als je de MD5-hash client-side maakt, is de enige manier van onderscheppen nog hopen op iemand zonder Javascript geactiveerd, en dan packets sniffen als het over gewone HTTP gaat. Dat of de verstuurde MD5-hash pakken en'n script schrijven dat MD5-hashes genereert en deze vergelijkt. Kans op zo'n zaken is al wel heel klein (niet onbestaande, maar heel klein). Als er iemand daar toevallig een oplossing voor kent, zodat de beveiliging volledig dicht is, laat maar weten, ben wel geïnteresseerd

Goh ja, je kan het al wat moeilijker maken door het paswoord in verschillende hash formaten te versturen (md5, dubbele md5, etc.) en bovendien nog wat randomly created hashes te versturen en uiteraard niet te zeggen welke het veld is dat jij gebruikt om te vergelijken met het paswoord in de database.

Ik heb dit ook net gemerkt en stoor me hier enorm hard aan. Bij de klantendienst vinden ze dit "normaal". Onvoorstelbaar hoe laks Dommel omgaat met gevoelige klantgegevens.
Ik kan niet wachten tot iemand een SQL injectie vindt en alle wachtwoorden op straat komen te liggen (hoogst waarschijnlijk plain-text in de database opgeslagen). En gezien de competentie van die programmeur, zie ik dat best nog wel gebeuren.

Trouwens, er is geen enkele reden om het wachtwoord van klanten clientside te tonen/op te slaan. In welke vorm dan ook (dus ook geen hashes). Ga dan voor een token-based systeem, dat is veiliger en biedt veel meer mogelijkheden.

Goztow schreef:dubbele md5

Een dubbele hash is MINDER veilig dan een enkele! Je kan veel beter je invoer salten!

best dus niet op een publieke wifi de dommel crm gebruiken

En telkens je geschiedenis verwijderen. Want daar staat je wachtwoord ook in.

Bedankt voor de info, even mijn paswoord gaan veranderen.
Niet de beste oplossing, maar meer kan ik er zelf niet aan verbeteren.

Userbase

Dommel kwistig met paswoord?

Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?

Re: Dommel kwistig met paswoord?