Henrik wrote :
> ----------Svar til Jesper Stocholm-------
> Sorry jeg fik mailet dig. forkert knap.. beklager ydmygst
> \Henrik
> ---------Svar til NG------------
ok ... :)
>> stiller du krav til de passwords dine brugere anvender ? Selv den
>> bedste hash-funktion kommer til kort overfor passwords som
>> "password", "micro$oft" eller "britney".
>
> Det var nok en god ide. så skal man tilknytte en form for ordbog, med
> en masse most_used_passwords, det vil jeg prøve at rode med.. sådan en
> tekstfil må kunne findes derude et sted
det er nu ikke nødvendigt. Du kan også "blot"vælge at teste på, om
password indeholder både store og små bogstaver, tal og specialtegn samt
er af en mindste længde. Hvis du vil lave en totalt porno-model, så
implementerer du en adaptiv Markov-model, der givet et password fra en
bruger fortæller dig, om dette password med stor sandsynlighed stammer
fra et givet sprog (alfabet). Jeg har selv en drøm om en dag at gøre
dette.
>> SSL er altid godt ... men hvorfor vil du anvende det ? Det giver jo
>> noget overhead mht kryptering af al kommunikation. Du kan evt kun
>> bruge SSL på den side, hvorfra login valideres - og så ikke på resten
>> af sitet. Det vil hjælpe lidt på det.
>
> Det var primært til passwordtrafikken mellem brugeren og serveren
så synes jeg du skal kræve SSL til den fil, der validerer passwords og
evt den side, hvorpå man kan ændre dit password. Det bør imo være langt
nok. Læg mærke til, at du faktisk ikek behøver SSL på den side, hvor
passwordet indtastes.
>> I øvrigt: er det passwords-brugerID du forsøger at beskytte - eller
>> er det indholdet på siderne ?
>
> Begge.
Hvis du er bange for, at der sidder nogen og lytter til IP-trafikken til
og fra din server, så er du nødt til at have noget SSL - men prøv lige
overveje først, hvor vigtigt det er. Hvis du vil gøre patient-journaler
tilgængelige via din server, så er det nok nødvendigt ... men ellers
synes jeg du skal tænke over det igen.
> Prøver at sørge for at man ikke bare kan se brugerens password
> i klartekst hvis man skulle få fat i databasen. indholdet på siderne
> er også vigtigt at beskytte, og jeg er lidt bange for at min
> Session("loggedin")=True er for vag.
det tror jeg ikke den er - jeg har mig bekendt ikke hørt om, at der er
nogen, der har lavet en session-id overtagelse.
> Er der andre måder at beskytte siderne på der er mere effektiv?
hive stikket ud ? Digitale signaturer ? applets der (de)krypterer data ?
der er masser af måder ... men de skal jo passe til den løsning de skal
bruges i.
--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|