WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Vad är idéen med begränsningar i val av lösenord? (https://www.wn.se/forum/showthread.php?t=1048015)

linusoleander 2011-05-05 00:36

Vad är idéen med begränsningar i val av lösenord?
 
Man ser lite här och var siter som har en övre begränsningar för val av lösenord vid te.x registrering.

Någon som vet varför man inte tillåts ha ett lösenord innehållande konstiga bokstäver eller en längd över 32-tecken?

hnn 2011-05-05 08:45

En leverantör till en kund har begränsningar i sin programvara pga. begränsningar i tredjepartsmoduler.

Tex. Längd på artikelnamn osv.

Så begränsningarna kan vara krav från tredjepartsmoduler eller liknande. Själv tycker jag det är ganska löjligt att ett lösenord max får vara ett visst antal tecken .

linusoleander 2011-05-05 09:08

Citat:

Ursprungligen postat av hnn (Inlägg 20404293)
En leverantör till en kund har begränsningar i sin programvara pga. begränsningar i tredjepartsmoduler.

Tex. Längd på artikelnamn osv.[...]

Jag pratade dock explicit om lösenordet, inte några andra parametrar.

Citat:

Ursprungligen postat av hnn (Inlägg 20404293)
[...]Så begränsningarna kan vara krav från tredjepartsmoduler eller liknande. Själv tycker jag det är ganska löjligt att ett lösenord max får vara ett visst antal tecken

Frågan var som sagt varför begränsningen läggs i från första början.

coredev 2011-05-05 10:42

Lite som hnn var inne på, kan ha varit en extern eller intern resurs som satt en begränsning. Ett exempel är att en databasutvecklare godtyckligt tycker att alla nog bör klara sig på 10 tecken i lösenordet och därför sätter en varchar(10) som datatyp på kolumnen. Ett annat exempel är att man har en extern autentiseringsmodul i bakgrunden som i sitt api kräver att lösenordet max får vara 10 tecken långt. Gamla autentiseringsprotikol som RADIUS är nästan uteslutande uppbyggt på fält med fasta längder (t.ex. 16 bytes).

Jag kan förstå att man av säkerhetsskäl sätter en övre begränsning på runt 20 tecken. Ett så långt lösenord kopieras med stor sannolikhet från en textfil istället för att skrivas in, och det är inte riktigt ok.

linusoleander 2011-05-05 10:57

Citat:

Ursprungligen postat av coredev (Inlägg 20404308)
Lite som hnn var inne på, kan ha varit en extern eller intern resurs som satt en begränsning. Ett exempel är att en databasutvecklare godtyckligt tycker att alla nog bör klara sig på 10 tecken i lösenordet och därför sätter en varchar(10) som datatyp på kolumnen[...]

Med tanke på att SHA1- och MD5-hashar alltid är 32 tecken så förstår jag inte iden med att sätta ett tak på 10 tecken.

Jag menar; dom sparar väl inte lösenorden i klartext!?

Citat:

Ursprungligen postat av coredev (Inlägg 20404308)
[...]Jag kan förstå att man av säkerhetsskäl sätter en övre begränsning på runt 20 tecken. Ett så långt lösenord kopieras med stor sannolikhet från en textfil istället för att skrivas in, och det är inte riktigt ok.

Mina lösenord jag har är på drygt 25 tecken innehållande allt från ü till @.
Och ja, jag kommer ihåg dom :)

Sedan kan man ju fråga sig varför vissa siter bara tillåter a-z0-9.
Vill man nu att folk inte ska kopiera lösenorden från en text-fil så vore ett lösenord på 7 tecken innehållande valfria tecken från UTF-8s teckentabell relativt säkert.

coredev 2011-05-05 11:21

Jag påstår inte att det är rätt, klokt eller genomtänkt, jag bara radar upp några sannolika scenarion.

tartareandesire 2011-05-05 12:29

Det finns fortfarande ganska många som sparar lösenord i klartext, det är väl en möjlig förklaring.

Lukas 2011-05-05 14:21

Ser ingen vettig anledning öht. Då hashade lösenord har en fast bredd (vanligtvis 32) är begränsningen meningslös, och luktar klartext.

Bjorne 2011-05-05 15:03

Jag har hört en utvecklare motivera det: Om man pastar text i lösenordsfältet kan man skapa sig ett lösenord med ett konstigt tecken som man inte kan skriva in igen. Alltså är det vettigt att filtrera ut specialtecken så att inte användaren sabbar för sig själv. Ett idiotresonemang för ett idiotproblem från en idiot, men så var det sagt och mina invändningar sket de i.

eliasson 2011-05-05 19:31

Det låter som att lösenordet sparas i klartext med t ex varchar(MAX_TECKEN), helt klart.


Alla tider är GMT +2. Klockan är nu 08:11.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson