Kjetil ble paff da han så kravene til Verisure: – Det er dårlig sikkerhet, og jeg blir skeptisk til totalpakken [Ekstra]

[Martin Braathen Røise]

Kjetil ble paff da han så kravene til Verisure: – Det er dårlig sikkerhet, og jeg blir skeptisk til totalpakken [Ekstra]

[Yaricks]

Uansett om det er i praksis umulig å knekke lange passord så burde ikke firmaer som Verisure legge begrensninger på lengde på passord. Dersom passord ikke ligger lagret i klartekst, men hashes og saltes vil det ikke ha noe å si hvor langt passordet er - alle passord vil ha samme lengde i databasen uansett.

[Kjetil Klaussen]

Poenget mitt var at denne begrensningen er kun gjort i mobil-app'en (Android), mens begrensningen på passordlengde ikke finnes (såvidt jeg kan se) når man logger inn på nettsiden ("Mine sider"). Med andre ord virker det ikke som det er noen begrensinger på passordlengde i back-end, men av en eller annen grunn har de lagt inn denne begrensningen i mobil-app'en. Hva er poenget med det?

[Didrik Decibel]

ulv ulv...

[morten7]

Tester man litt på Gmail og Facebook vil man se at de automatisk kutter siste delen av passordet, så hva man skriver på slutten i et passord har ingen betydning med innlogging hvis det er «ekstremt» langt.

 

Vet ikke om det er rettet nå. Men var en Bug hos Verisure hvor man fikk tilgang til forrige brukers historikk 3mnd via APIet hvis man fikk overført alarmutstyret. Eks hvis man flytter.

Meldt til Verisure som mente det ikke var en feil. Selv om jeg tviler på at er helt ok i henhold til GDPR.

[timeshift]

Uansett om det er i praksis umulig å knekke lange passord så burde ikke firmaer som Verisure legge begrensninger på lengde på passord. Dersom passord ikke ligger lagret i klartekst, men hashes og saltes vil det ikke ha noe å si hvor langt passordet er - alle passord vil ha samme lengde i databasen uansett.

Grøss. Verisure burde utdype hvordan de lagrer passord, men får da håpe det ikke er dette som ligger til grunn. Lengdebegrensninger kan ha sine årsaker selv også om passord ikke lagres i klartekst. Eks. for å forhindre en teorietisk mulighet for tjenestenektangrep, men da snakker vi om ekstreme lengder og trafikk som uansett også burde begrenses på andre vis.

 

31 tegn er nokså kort, her kan det være verdt å minne Verisure om enkle setningspassord som fort kan bli nokså lengre. Denne setningen er lengre enn et 31 tegn passord.

 

OWASP fraråder også å sette en evt. maksgrense som er kortere enn 128 tegn: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md

[Gjest Slettet-Pqy3rC]

Det meste med disse sector/verisure greiene er ganske labert. Men, det er jo enkelt da - og sånt liker jo folk. Tanken er muligens at kjeltringene skal velge et annet hus når de ser disse klistremerkene, så utstyret/løsninger spiller vel mindre rolle egentlig.

 

Dog, litt motproduktivt blir det jo dersom kjeltringene tar over systemet og bare låser seg selv inn. Forsikringsselskaper pleier jo å redusere utbetalingene en del når det er gitt fritt leide.

[sveintore78]

Må ærlig innrømme at jeg har alarm for brannvarslingen sin del, pluss rabatten på forsikringen (ikke at den kompenserer for mye av utgiftene).

[tigerdyr]

Tja, jeg ville være mer bekymret for at de ansatte koser seg med å snoke i hva som skjer i de ulike hjemmene (de som velger å installere videoovervåking).  

[nomore]

Må ærlig innrømme at jeg har alarm for brannvarslingen sin del, pluss rabatten på forsikringen (ikke at den kompenserer for mye av utgiftene).

Men du setter sikkert pris på at utenforstående ikke kan følge med på aktivitet i boligen?

[007CD]

Skremmende mange som lagrer passord i klartekst.

Carnival Cruise lines som eier en god del andre, har passordene for booking i klartekst som kan vises av ansatte på skipene sine til eksempel.

 

Også er mange stor fan av å kryptere passord, hvor de da begrenser lengden for å ikke få for lange passord i databasene sine, noe som også er helt feil måte å gjøre det på.

[Yaricks]

Skremmende mange som lagrer passord i klartekst.

Carnival Cruise lines som eier en god del andre, har passordene for booking i klartekst som kan vises av ansatte på skipene sine til eksempel.

 

Også er mange stor fan av å kryptere passord, hvor de da begrenser lengden for å ikke få for lange passord i databasene sine, noe som også er helt feil måte å gjøre det på.

 

Dersom du krypterer passordene med f.eks. SHA256 e.l. vil alle passord ha nøyaktig samme lengde i databasen ettersom du bare får hash verdien i databasen.

[1TR4R69Q]

For en passordfrase er ikke nødvendigvis 32 tegn nok. Hvis en tar utgangspunkt i at en passordfrase består av ord plukket tilfeldig fra de 3000 mest brukte ordene på engelsk (som på engelsk dekker 95% av dagligtale, og har en snittlengde på ca åtte tegn), får en plass til rundt fire ord på 32 tegn.

 

3000^4 = 8.1*10^13 ~= 2^46.2

 

46.2 bit entropi er ikke dårlig, men ikke altfor mye heller.

[1TR4R69Q]

Dersom du krypterer passordene med f.eks. SHA256 e.l. vil alle passord ha nøyaktig samme lengde i databasen ettersom du bare får hash verdien i databasen.

 

SHA256 er ikke kryptering, det er hashing. Kryptering impliserer at plaintext kan hentes ut ved hjelp av en nøkkel, noe du ikke vil at skal være mulig med passord. SHA256 er forøvrig ikke egnet til passordhashing, da den er designet for å være rask. Algoritmer som scrypt er spesielt designet for passord, og er tvertimot deisgnet for å være kostbar - både i tid og rom - og vanskelig å parallelisere.