Firefox 51 geeft een http inlog als onveilig aan.

[Briolet]

Sinds gisteren is Firefox 51 uit. Deze versie geeft nu standaard een rood doorgestreept slotje op een http pagina waar een wachtwoord ingevuld moet worden.

Als je thuis dus gewend bent om de nas via http te benaderen zul je dit symbool gaan zien. Chrome is iets vergelijkbaars van plan vanaf versie 56. (Eind jan of begin febr.) (Edit: Een dag later, 26 Jan, is Chrome 56 uitgekomen)

Nu zijn het alleen nog de pagina's met wachtwoorden, maar in de toekomst zal Firefox alle http paginas dat doorgestreepte slotje laten zien.

Dit ter info voor mensen die zich afvragen waarom ze nu dat symbooltje zien als ze op de nas inloggen.

[Babylonia]

Met de toenemende internet criminaliteit lijkt me dat geen overbodige luxe.  Ik handel er toch al naar omdat ik me van de gevaren bewust ben.
Bij een website met "http" mocht ik een wachtwoord moeten invullen, verander ik die "http" in  "https" om te zien of dat ook voorhanden is.
(Dat is namelijk zeker niet altijd standaard).

Mijn eigen servers gaan automatisch reeds naar "https" en gebruik een SSL certificaat.

En het komt dus echt voor dat wachtwoorden worden gescand bij gebruik van openbare WiFi en gebruikers erna worden gehackt:
Zie eerder bericht op het forum < HIER > en de rest van het draadje, met aanbevelingen waar op te letten met maatregelen om veiligheidsrisico's te verminderen.

[Briolet]

Een inlog via http is niet per definitie onveilig. Het wachtwoord gaat echt niet altijd als plaintekst over het internet, zoals vaak beweerd wordt.

Toen deze website nog http gebruikte bij een inlog, heb ik wel eens met wireshark gekeken of ik mijn wachtwoord kon terugvinden. Dat lukte niet. Ik zag in de inlog procedure dat er een hash verzonden werd. Die moet dan eerst gekraakt worden.

Als je in de JS code van de inlogprocedure kijkt, zie je dat je wachtwoord ook nog ge-salt wordt met de session ID. Dus elke keer is die hash weer anders, wat het ook extreem moeilijk maakt om te kraken.

Voor de aardigheid. De gebruikte code die ik zie om het wachtwoord te coderen:

Code: [Selecteer]

doForm.hash_passwrd.value = hex_sha1(hex_sha1(doForm.user.value.php_to8bit().php_strtolower() + doForm.passwrd.value.php_to8bit()) + cur_session_id);Het wachtwoord wordt dus in de browser gehashed, vervolgens wordt de session ID toegevoegd en dan weer gehashed. Deze dubbele hash gaat het internet op.

De eerste hash zal op de server opgeslagen zijn. Daar zal deze hash ook met het session ID gehashed worden. Dat resultaat zal dan vergeleken worden met de ontvangen data van de inlogger.

Het probleem van een http inlog is dat je op voorhand niet weet hoe je wachtwoord verstuurd gaat worden, dus kun je er beter van uitgaan dat dit zichtbaar zal zijn.

[Babylonia]

Het probleem van een http inlog is dat je op voorhand niet weet hoe je wachtwoord verstuurd gaat worden, dus kun je er beter van uitgaan dat dit zichtbaar zal zijn.

Dat is de essentie van het achterliggende idee. 

[Briolet]

Gisteren heeft Safari een update gehad van 11.0.2 naar 11.1. Nu heeft ook Apple deze "niet veilig" tekst toegevoegd.

Ook zonder check of je gewoon lokaal inlogt en zonder check of het wachtwoord ook bij http gecodeerd verstuurd wordt



Ergerlijk, want ik weet dat mijn lan veilig is. (Zo niet, dan heb ik een heel ander probleem dan alleen de inlog) En op een deel van mijn camera's en ook op mijn router kan ik niet eens een certificaat zetten.

Mijn mening is echter dat je je niet mag aanleren om zo'n melding te negeren. Want als je dit routinematig gaat negeren, doe je het ook als de melding terecht is.

[Briolet]

Ik merk dat de "Niet veilig" melding bij de nieuwe Safari wel weg blijft als ik via IP adres inlog i.p.v. een locale domeinnaam.

Apple maakt dus wel een uitzondering voor private adressen maar doet bij domeinen geen lookup om te zien of die naam ook lokaal is. Er is beter over nagedacht dan bij Firefox of Chrome, maar nog niet genoeg.