petterg Skrevet 22. august 2004 Del Skrevet 22. august 2004 Er det noen måte å lage en webside hvor en bruker kan endre passord for en database uten å sende det faktiske passordet over nett? Har en løsning i dag hvor det nye passordet sendes i "klartekst" over en ssl forbindelse. Det resulterer i at passordet er lesbart i klartekst i systemloggen hvis systemet er satt opp til å logge POST. Dette vil jeg altså ungå Lenke til kommentar
Smidt Skrevet 22. august 2004 Del Skrevet 22. august 2004 du kan vel md5 krytere det. altså $newpass =$_POST["newpass"]; $newpass=md5($newpass); går vel ikke an å kryptere noe før det. Lenke til kommentar
jorgis Skrevet 22. august 2004 Del Skrevet 22. august 2004 Du kan kryptere passordet hos klienten med JavaScript. Er ganske sikker på at JavaScript har en egen md5()-funksjon. Husk at du ikke må anta at brukeren allerede har JS påslått, og må kjøre en sjekk hver gang, samt ha en backupløsning i f.eks. PHP. Lenke til kommentar
petterg Skrevet 23. august 2004 Forfatter Del Skrevet 23. august 2004 (endret) Men når passordet sendes md5 cryptert til server, så blir jo passordet i praksis lik md5 summen. Alså en som snuser i loggen vil kunne se md5 summen, og så logge seg ved å bruke md5 summen som passord! Edit: decryptering av md5 er for komplisert til at server kan gjøre det hver gang noen endrer passord Endret 23. august 2004 av petterg Lenke til kommentar
audunr Skrevet 23. august 2004 Del Skrevet 23. august 2004 Har du tenkt på å bruke SSL? MVH Audun Lenke til kommentar
Torbjørn Skrevet 23. august 2004 Del Skrevet 23. august 2004 som sagt, du kan kryptere passordet i javascript hos klienten før det sendes, og så lagre dette krypterte passordet direkte i tabellen, men hvordan har du tenkt å gjøre påloggingen? hvis du siden logger på ved å sende det nye passordet i klartekst er du like langt. bruker du md5 summen ved inlogging, så sendes denne i klartekst. å sende over SSL er stort sett så bra man kan få det. Lenke til kommentar
petterg Skrevet 24. august 2004 Forfatter Del Skrevet 24. august 2004 Innlogging skjer slik: (php på server, html og js på klient. All kommunikasjon går over ssl.) Passord er f.x. lagret som mysql's passwd(pass) i databasen Server: $seed = random string Server: genererer innloggings html og js hvor en variabel i js = $seed Klient: Bruker skriver inn user, pass og trykker submit Klient: js: md5sum(user + passwd(pass) + $seed) Klient: js: poster user og md5sum på server. Server: henter passwd(pass) fra databasen Server: md5sum(user + passwd(pass) + $seed) Server: dersom md5sumen fra client stemmer med den servergenererte er brukeren authentisert. Dette forutsetter at man vet hvilken passordkryptering mysql bruker, og lage en js kode som gjør det samme. Hmm. Ved å skrive denne forklaringen ser jeg jo svaret på mitt eget spørsmål... det er jo bare å kryptere med mysql's passdw i javascriptet før det sendes. Noen som kjenner hvilken kryptering som mysql bruker i passwd? Noen som tilfeldigvis sitter på en kodesnutt som gjør slik kryptering? (Om det ikke allerede er en standard funksjon) Noen som vet/har tilsvarende js kode for krypteringen som brukes i /etc/shadow? Og for samba? Lenke til kommentar
Torbjørn Skrevet 25. august 2004 Del Skrevet 25. august 2004 sett deg tilbake og tenk over hva som egentlig skjer. ditt problem er følgende: folk som lytter på linja di ser passordet. har det så noe å si om du sender passordet kryptert eller om du sender det i klartekst? det som sendes over nettet er likevel det som autentiseres. hvis du autentiseres vha et kryptert passord, så er det bare for snifferen å sende det krypterte passordet (som han allerede har sniffet) Lenke til kommentar
petterg Skrevet 25. august 2004 Forfatter Del Skrevet 25. august 2004 sett deg tilbake og tenk over hva som egentlig skjer. ditt problem er følgende: folk som lytter på linja di ser passordet. har det så noe å si om du sender passordet kryptert eller om du sender det i klartekst? det som sendes over nettet er likevel det som autentiseres. hvis du autentiseres vha et kryptert passord, så er det bare for snifferen å sende det krypterte passordet (som han allerede har sniffet) Derfor man har en random seed. Dersom noen sniffer det krypterte passordet, så vil denne krypterte nøkkelen allerede være brukt opp. Så hvis noen sender den samme krypterte strengen vil den ikke lenger være gyldig. På klientsiden må man kjenne både krypteringsalgoritmen og det krypterte passordet for å kunne svare riktig på neste seed. (ulempen med dette er at dersom en bruker trykker "back" i browseren vil han bli logget ut.) For authentisering er dette en god nok løsning. For endring av passord er den på kanten. Jeg tar utgangspunkt i at ssl forbindelsen i er trygg. Det jeg ville ha bort var at passordet blir stående i klartekst i en logg. Dermed kan sysadmin lese i loggen uten å få vite alle passord, og folk som leser over skulderen må huske en kryptert streng og senere klare å dekryptere den. Selv om det er en svakhet er det en enorm forbedring. Tar selvsagt imot forslag til bedre måter å gjøre dette på! Lenke til kommentar
Torbjørn Skrevet 25. august 2004 Del Skrevet 25. august 2004 det er sjelden man logger POST data, sender du form med POST er du sannsynligvis trygg. Lenke til kommentar
Torbjørn Skrevet 25. august 2004 Del Skrevet 25. august 2004 hvordan har du tenkt å løse problemet med neste seed? jeg kan vanskelig se hvordan det kan la seg gjøre bare vha HTTP og standard web browsere. man kan be brukeren skrive ned en seed som må tastes inn som input til js ved neste autentisering. Noe jeg nok ikke hadde blitt glad for som bruker. serversertifikater er en annen måte, det løser nok det du er ute etter å løse, men hvordan dette gjøres i praksis vet jeg ikke (det koster penger) Lenke til kommentar
petterg Skrevet 25. august 2004 Forfatter Del Skrevet 25. august 2004 php genererer også js kode. Bruker må ha på js for å få postet formet. Dermed kan php generere random seed og js får den for å utføre krypteringen. Jeg skal bruke dette i et litt større omfang enn html, php, mysql. Dermed kommer deler av POST (bl.a. passordet) i loggen enten man vil eller ikke. Sliter med å finne ut hvordan krypteringsalgoritmene er..... Lenke til kommentar
Torbjørn Skrevet 26. august 2004 Del Skrevet 26. august 2004 kanskje du finner noe her Lenke til kommentar
petterg Skrevet 26. august 2004 Forfatter Del Skrevet 26. august 2004 Mysql baserer seg på crypt for passord kryptering. Dvs jeg må finne algoritmen som brukes i crypt. Har foreløpig funnet ut at det ikke er md5 som brukes. (Mulig jeg må se på kildekoden til crypt for å finne ut av dette.) Ved bruk av crypt klarer jeg å lage krypterte passord som blir lik de mysql lagrer. Men dette passer ikke med hva som lagres i shadow. Hva brukes i shadow? Lenke til kommentar
Torbjørn Skrevet 26. august 2004 Del Skrevet 26. august 2004 hvorfor ikke bruke mysql sin md5() istedet? Lenke til kommentar
petterg Skrevet 26. august 2004 Forfatter Del Skrevet 26. august 2004 hvorfor ikke bruke mysql sin md5() istedet? Fordi mysql bruker crypt når den lagrer passord i mysql databasen. Det er bl.a. disse passordene som skal kunne endres via browser. Lenke til kommentar
Ueland Skrevet 27. august 2004 Del Skrevet 27. august 2004 fikk senest i går en klage på at det var et sikkerhetshull at passordet ble vist for brukeren.. passordet må vises en eller annen gang for brukeren, det må lagres et sted, hvis brukeren mister det så er det vel logisk at det blir resatt istedet for at det eksisterende passordet vises ja? man kan tenke på alle tenkelige måter noe kan gå galt på men enda kan passordet slippe ut, da som regel mange pleier og skrive ned passordene sine.. Lenke til kommentar
petterg Skrevet 28. august 2004 Forfatter Del Skrevet 28. august 2004 Passord skal ikke vises for brukeren. Og heller ikke være tilgjengelig for sysadmin. Mange bruker samme passord flere steder, og hvis sysadmin finner passordet vet han også passordet mange andre steder. Målet med denne tråden er å finne en måte å overføre passordet kryptert hele veien fra bruker til lagring. Det er en forutsetning at enere authentisering skal gjøres på bakgrunn av selve passordet, ikke ved bruk av den krypterte strengen som ble generert fra passordet. Samtidig må innlogging og authentisering fungere ved innlogging lokalt, altså uten at noe script gjør jalla ting med passordet brukeren taster inn. NTNU har en webside hvor man kan endre system-passord. Noen som vet hvilken metode de har brukt? Går utifra at de har en litt avansert løsning på dette! Lenke til kommentar
Torbjørn Skrevet 29. august 2004 Del Skrevet 29. august 2004 de sender sannsynligvis passordet i klartekst over en kryptert linje og har en server hvor et phpskript får kjøre med rettigheter til å oppdatere bdb. Lenke til kommentar
Torbjørn Skrevet 29. august 2004 Del Skrevet 29. august 2004 idet du lar et system autentisere passordet ditt, har du ingen kontroll på at sysadmin når som helst kan kode om systemet og lagre passordet du sender i klartekst. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå