Input password ?

Hejsa fusion-it

Først og fremmest er "selve" koden i et DB felt en meget dårlig ide! :)

MD5 kryptering af passwords er en god ide, det andet er simpelthen for usikkert.

http://www.asp-faq.dk/article/?id=52
http://www.rowl.dk/Articles/310    <- Der er der lidt om MD5 kryptering.

Når du så får dem krypteret så behøver du ikke være bange for at de måske ligger i kildekoden, da de er krypteret.

Takker :) jeg vargodt klar over det er usikkert men kikker lige på dine links og smider point senere :)

Jeg kan ikke helt gennemskue problemstillingen...

Hvis en bruger har et kodeord stående i sin browser, er det vel fordi denne bruger kender kodeordet i forvejen (for du sender vel ikke kodeord ud til klienten, hvis folk ikke skal bruge det!? :-)). Hvis brugeren kender kodeordet, kan det vel i principet være ligemeget om det kan findes som klartekst i kildekoden bagved...?

Mht. om det er sikkert at have kodeordet stående som klartekst i databasen, så kommer det vel an på hvordan data ellers opbevares i databasen. Hvis alt andet indhold ligger som klartekst, vil jeg sætte spørgsmåltegn ved, hvor værdifuldt det er, at kodeordet er krypteret... de data man måtte have interesse i at få fat i, kan man jo bare kigge på (hvis man nu engang har fået sneget sig adgang til databasen...). Det er klart, at hvis kodeordet giver adgang til en masse andet end databasen (resurser på netværket bag ved en firewall eller sådan noget, så er det naturligvis relevant at beskytte kodeordet så godt som muligt...

#Hvis brugeren kender kodeordet, kan det vel i principet være ligemeget om det kan findes som klartekst i kildekoden bagved...?

Nej det kan det ikke da dette her bruges i et CMS, jeg har så lavet et bruger administrations modul her kan man ændre bruger tildele nyt password, det er her det står som prikker. Hvis jeg lader dem være tomme skal man jo give nyt password hvis man kun ønsker at ændre bruger navn eller mail adresse, dette er ikke hensigtmæssigt:)

Du har da ret i det afhænger af hvordan DB er opbevaret men man skal nok mere vurdere lidt på hvilken side man har liggende og hvad den behandler :)

Det vil ALTID være usikkert at have password liggende på DB kommer en haj ind har han jo stort set adgang til det hele igen skal man vurdere på siden som bruges.

Men ingen tvivl om det sikkerste er kryptering!

Hvis kodeordet sendes ud på klienten bare for at markere kodeordet med prikker, så findes der andre metoder som sikrer kodeordet bedre. At kodeordet bliver opdateret sammen med resten kan du vel styre idet du gemmer data, i og med du kan sørge for kun at ændre kodeordet, hvis der rent faktisk er indtastet noget i feltet (jeg antager ikke du tillader blanke kodeord, når nu du argumenterer så varmt for kryptering og sikkerhed ;-)).

Ok lad mig lige forklare så, jeg har bygget et ret omfattende CMS, det er skrevet i asp på MYsql DB eller access DB. Ikke for at starte en diskusion men det med access er med fuldt overlæg da der findes firmaer/personer som foretrækker access, så diskution om dette er optimalt eller ej er her med i jorden :)
I dette CMS findes der et bruger modul, her kan man oprette brugere samt rette i dem evt slette. Når man så vil rette en bruger kommer man til en siden hvor man får brugerns oplysninger op i en form. Denne form indeholder så også 2 password felter (2 fordi der valideres) her henter jeg password in fra db så hvis bare man vil rette brugeren email ja så skal man ikke ændre brugerens password, dette er så en nem work around for at programmere mig ud af en løsning som ikke vil give de problemer.
Jeg har dog ikke været i stand til at gennemskue hvordan jeg skal skrive dette i asp.

men du skriver:
så findes der andre metoder som sikrer kodeordet bedre
Har du evt lidt link til noget af det, var nok mere det jeg søgte?


Jeg syntes da eller andet sted ikke man kommer uden om at kryptering er no 1 jeg mener hvis du havde 1 mill i kontanter ville du så ikke hellere sætte dem i banken end at låse dem i et pengeskab derhjemme?

Mht. din analogi til penge, bank og opbevaring hjemme, så vil jeg mene at pengene allerede står i banken og der ville jeg nok lade dem stå! ;-)

Der er flere aspekter i dette setup. Du snakker om sikkerhed og samtidig om lette løsninger - jeg har ikke super meget erfaring med høj sikkerhed, men for mig lyder det ikke som to koncepter der går i spænd :-)

Hvis du vitterlig vil være sikker på at data ikke kan aflures, så lader du være med at eksponere dem i nogen som helst form udenfor serveren, i første omgang, og gemmer dem laaangt væk på serveren, hvis du vil sikre dig mod crackere der får adgang til din server.

Så at sende kodeordet til klienten (uanset om det er krypteret eller ej), bare for at undgå, at skulle kode dig ud af udfordringen i forbindelse med lagringen af brugerens data, det virker som en selvmodsigelse.

Under antagelse af at du ikke kører over SSL (eller på anden måde er i stand til at kryptere data der sendes til serveren), er det jo stadig ikke sikkert i det tilfælde brugeren indtaster et nyt kodeord. Hvis det bliver sendt over en åben linje i klartekst, så er alle de "besværligheder" du går igennem for at sikre det eksisterende kodeord tabt, ligeså snart det ændres. Dette kan sikres ved at benytte SSL, men det kræver jo et cerifikat (som du kan købe, eller sætte din egen certifikatserver op, som du så skal have folk til at stole på ;-)).

Jeg kan ikke umiddelbart komme i tanke om nogen anden metode, der kan sikre dit systems kodeord, end at benytte SSL når kodeordene skal ændres (i praksis ville jeg nok køre hele admin-systemet over SSL) og så undlade overhovedet at sende kodeord til klienten.

Jeg kom, i mit forrige indlæg, med et forslag til, hvordan du kunne håndtere en opdatering af kodeordet (blank kodeord = ingen opdatering af kodeordet), men har i øvrigt ikke lige nogle links til konkrete løsninger på din udfordring.

Hvis du vil have prikker i kodeordsboksen, så sæt et fast antal prikker og filterer dem, enten ved afsendelse af formularen, eller på serveren når du modtager et postback...

Husk lige jeg satte den til du havde dem i kontanter :))


Der er flere aspekter i dette setup. Du snakker om sikkerhed og samtidig om lette løsninger - jeg har ikke super meget erfaring med høj sikkerhed, men for mig lyder det ikke som to koncepter der går i spænd :-)
Læs mit første indlæg, her vil du opdage jeg sådan set ikke nævner sikkerhed, dette kommer på banen fra mjdigital :) Jeg søget bare en måde at skrive passwordet ud til klienten på :)

Så jeg kan sige det på en anden måde syntes jeg vi skal lade sikkerhedes delen ligge og finde en løsning som ikke omhandler sikkerhed da min mening stadig er den, at sikkerheds niveau afhænger af kunden som bruger det.

Måske andre har en løsning på dette ?

Jeg kom, i mit forrige indlæg, med et forslag til, hvordan du kunne håndtere en opdatering af kodeordet (blank kodeord = ingen opdatering af kodeordet), men har i øvrigt ikke lige nogle links til konkrete løsninger på din udfordring.

Ok så misforstod jeg da da du skrev Hvis kodeordet sendes ud på klienten bare for at markere kodeordet med prikker, så findes der andre metoder som sikrer kodeordet bedre.

"Husk lige jeg satte den til du havde dem i kontanter :))". Ja, det er muligt, men det er bare ikke det der er tilfældet, for passwordet (pengene) ligger på serveren (banken) og der mener jeg det skal blive... ;-)

Mht. sikkerhedsdisukssionen, så OK, men du var selv ret hooked på sikkerhed i dine efterfølgende indlæg, så jeg antog du havde taget det til dig :-)

Hvad er det ved de to forslag jeg har stillet indtil videre, du ikke kan lide? Det kan være jeg kan tweake dem lidt (det er jeg faktisk ret sikker på), så du kan bruge dem til noget...

Mht. din afsluttende bemærkning: "Måske andre har en løsning på dette?"... vil jeg give dig et lille velmenene råd til din færden på eksperten: lad for Guds skyld være med at "afvise" folk, bare fordi de ikke lige rammer dit behov med det samme - der ligger rigtig mange gode erfaringer gemt i en del folk her på sitet, som du kvit og frit får adgang til, hvis du eller forholder dig lidt ydmyg. Du ved det nok fra dig selv, når du hjælper andre herinde (hvilket jeg har set dig gøre i flere indlæg efterhånden) - det er rarest når folk modtager dig med et åbent sind og modtagelig overfor input.

Ad #9: Jeg mener i princippet ikke et eksisterende kodeord har noget at gøre ude på klienten igen, det er en "one shot only" (eller "write only" om du vil) information. Hvis det skal ændres, så gør du bare det, men du læser det ikke fra hjemmesiden igen.

Hvis du vil indikere overfor brugeren af dit system, at der er et kodeord og kodeords længde (hvilket igen heller ikke er god praksis), så aflæs det antal tegn kodeordet fylder og send det antal "prikker" til klienten (f.eks. i form af asterisk eller mellemrum). Når formularen kommer tilbage til serveren, kan du kontrollere om value af password kun består af "prikker" og så undlade at opdatere passwordfeltet, hvis dette er tilfældet. I øvrigt samme metode som med det blanke password, men altså bare en anden restriktion, dvs. et password må ikke kun bestå af "prikker" (asterisk, mellemrum eller whatever).

#softspot
Tak for dit råd men jeg har ikke på noget tidspunkt afvist dig :)Jeg har nu ikke kun oprettet dette inlæg for en bestem person så det er dafor mig ret naturligt at høre om andre løsninger :)

Hvad er det ved de to forslag jeg har stillet indtil videre, du ikke kan lide? Det kan være jeg kan tweake dem lidt (det er jeg faktisk ret sikker på), så du kan bruge dem til noget...
Jamen jeg har intet imod dit forslag men du skriver jo bare det kan lade sig gøre du kommer ikke rigtigt med noget konkret andet end det kan lade sig gøre.

Men kan da se du så nu kommer med en konkret løsning som jeg kan forholde mig til :)
#11
Den løsningen har jeg haft oppe og vende men syntes et sted det er for meget arbejde i forhold til hvad man får ud af det :) Derfor skrev jeg her om det måske skulle findes en nem lille fix løsning som jeg har overset :) Hvis du kikker på #1 ja så spørg og faktisk til det her men strakt kommer emnet på afveje og vi ender et sted hvor jeg ikke søger hjælp :))

Hvori består det besværlige i den løsning? Hvis du kan vise mig koden omkring det sted hvor brugerens oplysninger skal gemmes igen, kan det være jeg kan komme med et helt konkret forslag, men lige nu vil det helt naturligt blive lidt abstrakt, da jeg ikke ved hvad jeg har med at gøre... :-)

Ok jamen det kan godt lade sig gi sig jeg smider lige en min mail til dig privat så kanvi ordne det der .... og jeg skal nok husk at skrive løsningen her så andre kan få glæde af den :)

Fik du mit svar?

ja det gjorde jeg og er igang fuld gang ))

OK :-)

Så fandt vi en løsning som ikke indebære kryptering :)

Softspot hjalp mig med dette og vil da lige benytte lejligheden endnu engang at takke :)


Sammen med mit SQL kald kalder jeg dette :
pass = space(len(rs("p"))) /* Dette laver password om til tomme tegn.


I stdedet for at skrive passwordet ud i min input som jeg før gjorde :
<input type="password" name="ord" class="user-field" value="<%=rs("p")%>" /> 

Skriver jeg nu min variabel fra toppen ud :
<input type="password" name="ord" class="user-field" value="<%=pass%>" /> 

I filen hvor jeg udøre selve opdateringen skriver jeg:
if trim(ord) = "" then
  ' undlad at opdatere kodeordet, hvis der kun er mellemrum i kodeordet...
  SQL = "Update......
else
  ' opdater kodeordet da der er indtastet noget nyt (selvom det rent faktisk godt kunne være det samme kodeord igen).
  SQL = "Update ..............

Job done :) Skriv til mig for nærmere forklaring!

Softspot smider su et svar ? :)

Jeps! Velbekomme :-)

Tak for point :-)

Lige en rettelse:

if trim(ord) = "" then
  ' Denne løsning går i else delen

Løsning:
if Request.Form("ord") = "" then