Wachtwoord Plain-Text verstuurd, "eigen codering"

Welke 'encryptie' ze ook gebruiken. Doordat ze de wachtwoorden plain over te mail sturen blijft het een security lek. Wat stom dat er nog dergelijke bedrijven zijn die dit zo doen zeg. Ongelooflijk.

Wat heeft een wachtwoord in je email te maken met de encryptiewijze in de database? Misschien slaan ze deze, zoals ze zelf ook zeggen, wel gewoon encrypted op. Alleen decrypten ze deze en plain text emailen ze deze naar je.

Als je nou voorstelt om NIET meer plain text wachtwoorden te versturen, maar een mooi linkje waar je je wachtwoord kan veranderen etc, dan kan ik het begrijpen.

Orion84 schreef op dinsdag 20 september 2016 @ 08:28:
[...]
De vraag bij dit soort methodes is echter wel vaak: hoe goed is die sleutel beveiligd. Kan een hacker die de database kan stelen ook de sleutel opvissen van het systeem?

En daarom wil je wachtwoorden dus niet versleutelen, maar hashen. Bijv. bcrypten met een voldoende lange individuele salt. Dan loop je niet het risico dat je het slot én de sleutel tegelijk weggeeft bij een hack.

Encryptie kun je altijd ongedaan maken (decrypten). Hashing gaat altijd maar een kant op. Zodra je het zelfde (wachtwoord) invoert komt er dezelfde code uit die je dan kan vergelijken met de code in je database, grof gezegd.

Wachtwoorden wil je altijd hashen! De beheerders en eventuele hackers kunnen nu dus altijd jouw wachtwoord zien.

Veel mensen gebruiken ook overal het zelfde wachtwoord. Leuk als de beheerder in kan loggen op je mail.

Je kan dit soort dingen vast ergens melden maar waar weet ik niet.

Wat jij bedoelt is hashing: onomkeerbare versleuteling. Dit passen ze niet toe, want een hash is niet meer te herleiden naar de oorspronkelijke waarde.

Wat ze waarschijnlijk toepassen: symmetrische versleuteling. Je wachtwoord wordt versleuteld met een sleutel, en diezelfde sleutel kan je wachtwoord ook weer ontsleutelen. Inderdaad minder veilig, hierbij is het wachtwoord wel te achterhalen met behulp van de sleutel.

Groot verschil

[ Voor 13% gewijzigd door P1nGu1n op 20-09-2016 08:36 ]

Alle wachtwoorden worden momenteel door middel van een eigen codering opgeslagen. Uw wachtwoord is dus veilig in onze database.

Daar gaan sowieso al mijn nekharen van overeind staan. Tenzij je een paar jaartjes rond hebt gelopen op de KU Leuven onder de begeleiding van Dhr. Rijmen moet je sowieso ver weg blijven van een zelf gebakken implementatie. Kans dat daar gaten in zitten is ongeveer 100%.

Maar ja, er is überhaupt 0,0 argumentatie waarom je wachtwoorden wil encrypten ipv hashen. Ik zou er dus voor zorgen dat je je wachtwoord nergens anders gebruikt.

[ Voor 6% gewijzigd door Standeman op 20-09-2016 09:04 ]

Hebben ze het via https verstuurd? Dan zou je nog enige bescherming hebben op het web?
Ja, op je pc is het dan wel zo te vinden.

beascob schreef op dinsdag 20 september 2016 @ 09:12:
Hebben ze het via https verstuurd? Dan zou je nog enige bescherming hebben op het web?
Ja, op je pc is het dan wel zo te vinden.

Nee, per email

-

[ Voor 100% gewijzigd door Firefly III op 21-10-2019 09:31 . Reden: Leeg ivm privacy ]

beascob schreef op dinsdag 20 september 2016 @ 09:12:
Hebben ze het via https verstuurd? Dan zou je nog enige bescherming hebben op het web?
Ja, op je pc is het dan wel zo te vinden.

Mail wordt doorgaans via SMTP verstuurd. De S hierin staat voor simple, niet voor secure.

JCE schreef op dinsdag 20 september 2016 @ 09:37:
Het feit dat ze het wachtwoord opnieuw kunnen opzoeken betekent dat ze encryptie en decryptie gebruiken. Dat is al te kansloos voor woorden en het wachten is dan ook op een datalek dat ze naar het AP mogen sturen.

Dat ze die wachtwoorden bij elk wissewasje opsturen is ook verschrikkelijk.

Ik zou mezelf asap uitschrijven bij deze prutsers.

Zo'n beetje elke Usenet Service Provider stuurt plain-text de wachtwoorden naar de klanten, tenminste, in elk geval bij die waar ik lid bij ben (geweest).

[ Voor 47% gewijzigd door CH4OS op 20-09-2016 09:43 ]

In ideale omstandigheden sla je geen wachtwoorden op maar enkel de hashes. Ook de hashes zijn eventueel te herleiden tot het wachtwoord maar daar moet een aanvaller een pak meer tijd en moeite insteken.

De methode die je provider hier gebruikt kan veilig zijn als er gebruik gemaakt wordt van een sleutel die de aanvaller niet eenvoudig kan bemachtigen, bv. een USB dongle die in de server zit.

Deze site heeft een goede samenvatting over dit onderwerp en een plek om 'overtreders' te rapporteren: http://plaintextoffenders.com/faq/non-devs

P1nGu1n schreef op dinsdag 20 september 2016 @ 08:35:
Wat jij bedoelt is hashing: onomkeerbare versleuteling. Dit passen ze niet toe, want een hash is niet meer te herleiden naar de oorspronkelijke waarde.

Hoewel hashing een one way encryption algorithm is zijn gehashde wachtwoorden wel degelijk kwetsbaar voor aanvallen met behulp van rainbow tables.

Wikipedia: Rainbow table

Dus een hash is wel degelijk in bepaalde gevallen te herleiden naar de oorspronkelijke waarde.

Orion84 schreef op dinsdag 20 september 2016 @ 08:28:
De eigenaar van versleutelde data heeft doorgaans de decryptiesleutel en kan dus logischerwijs inderdaad makkelijk decrypten. Dat staat compleet los van de sterkte van de encryptiemethode en hoeveel moeite het een hacker zou kosten die bijvoorbeeld wel de versleutelde database buitmaakt, maar niet de sleutel.

De vraag bij dit soort methodes is echter wel vaak: hoe goed is die sleutel beveiligd. Kan een hacker die de database kan stelen ook de sleutel opvissen van het systeem?

Omdat jouw antwoord als beste antwoord is geselecteerd is het goed te benadrukken dat een goed wachtwoordsysteem zo niet werkt. Een beheerder zou in principe nooit toegang moeten en hoeven hebben tot de wachtwoorden van zijn gebruikers. Zoals hier in het topic al uitgelegd wordt, wordt doorgaans met hashes en dan liever ook salts gewerkt. Zo kent alleen de gebruiker zijn wachtwoord.

WhiteDog schreef op dinsdag 20 september 2016 @ 09:49:
De methode die je provider hier gebruikt kan veilig zijn als er gebruik gemaakt wordt van een sleutel die de aanvaller niet eenvoudig kan bemachtigen, bv. een USB dongle die in de server zit.

Welke extra laag beveiliging zou een USB-dongle toevoegen?

Verwijderd schreef op dinsdag 20 september 2016 @ 10:17:
[...]

Omdat jouw antwoord als beste antwoord is geselecteerd is het goed te benadrukken dat een goed wachtwoordsysteem zo niet werkt. Een beheerder zou in principe nooit toegang moeten en hoeven hebben tot de wachtwoorden van zijn gebruikers. Zoals hier in het topic al uitgelegd wordt, wordt doorgaans met hashes en dan liever ook salts gewerkt. Zo kent alleen de gebruiker zijn wachtwoord.

Mijn reactie was dan ook specifiek een antwoord op Imnoa in "Wachtwoord Plain-Text verstuurd, "eigen codering"" en inderdaad niet in algemeenheid een antwoord op de vraag in de topicstart. Ik ben het helemaal met je eens dat het over het algemeen een veel beter idee is om hashing te gebruiken dan encryptie (en het mailen van wachtwoorden is natuurlijk al helemaal hopeloos).

Verwijderd schreef op dinsdag 20 september 2016 @ 10:16:
[...]


Hoewel hashing een one way encryption algorithm is zijn gehashde wachtwoorden wel degelijk kwetsbaar voor aanvallen met behulp van rainbow tables.

Wikipedia: Rainbow table

Dus een hash is wel degelijk in bepaalde gevallen te herleiden naar de oorspronkelijke waarde.

Daarvoor zijn er seeds uitgevonden Wanneer je SHA-256 gebruikt met een goede seed, wens ik je veel succes met een rainbowtable

MD5 zonder seed is daarentegen een eitje.

[ Voor 3% gewijzigd door Standeman op 20-09-2016 10:38 ]

Zo zijn er wel meer usenet providers die dit zo doen, vorig jaar eentje gesproken (ivm andere internetaansluiting), die gaf enkel aan dat dit @random gemaakte username/wachtwoorden zijn en ze allemaal expiratiedatum hebben. In het ergste geval kan dit dus een 3-6maanden versie zijn, waar upload niet mogelijk is en download vast zit aan een cap.

Ongeacht wat voor encryptie methodes ze gebruiken, puur alleen al het feit dat ze indien gewenst zelf alle wachtwoorden zo kunnen uitlezen.

Een wachtwoord hoef je nooit ergens voor uit te kunnen lezen. Vandaar dat het normaliter allemaal eenrichtings verkeer is. Als hun key lekt dan is direct alles openbaar. Hoe makkelijk wil je het een hacker maken?

Nee, ik zou direct naar een andere concurrent gaan. Sterker nog, dat is mijn standaard actie wanneer ik plain text wachtwoorden terug krijg.

Standeman schreef op dinsdag 20 september 2016 @ 10:37:
Daarvoor zijn er seeds uitgevonden Wanneer je SHA-256 gebruikt met een goede seed, wens ik je veel succes met een rainbowtable

MD5 zonder seed is daarentegen een eitje.

Daar moet wel een nuance in aangebracht worden. Als de database gecompromitteerd wordt, liggen de seeds vaak ook op straat. Het is weliswaar vrijwel onmogelijk om een rainbow table in elkaar te zetten met lange salts, maar individuele wachtwoorden met lange salts kunnen met SHA-256 nog steeds relatief snel gekraakt worden.

Het inherente probleem aan het SHA-256 algoritme is dat deze extreem efficient te berekenen is. High end consumenten hardware (game PC met twee high-end videokaarten bijv.) kan met gemak 1 miljard hashes per seconde uitrekenen. Stel dat je een wachtwoord hebt van 6 tekens (met een hash van 32 tekens), dan is deze theoretisch te bruteforcen in minder dan 1 minuut.

De enige goede oplossing voor password hashes is een hashing methode welke erg intensief is om te berekenen. Vandaar dat ik in mijn eerdere post ook bcrypt aanhaalde. Mits goed ingezet kan een computer die 1 miljard SHA-256 hashes per seconde kan uitrekenen maar enkele tientallen brypts uitrekenen. En daarmee maak je het brute forcen van een wachtwoord effectief onhaalbaar met de hardware van vandaag.

Verwijderd schreef op dinsdag 20 september 2016 @ 10:16:
[...]


Hoewel hashing een one way encryption algorithm is zijn gehashde wachtwoorden wel degelijk kwetsbaar voor aanvallen met behulp van rainbow tables.

Rainbow tables zijn een tradeoff tussen opslagcapaciteit vs rekentijd en is ingehaald door de immense rekenkracht van moderne GPUs zoals Tweakers zelf ondervond in 2011 toen ze MD5 met salt gingen uitfaseren: plan: Analyse: zwakke wachtwoorden op Tweakers.net. Of dit recentere artikel over vBulletin passwords van beveiligingsonderzoeker Troy Hunt, waarbij hij al 3 miljard hashes per seconde haalt met een R9 290X uit 2013.

Kort antwoord op de TS: als ze wachtwoorden niet hashen met scrypt, bcrypt of PBKDF2 moeten er alarmbellen afgaan (bron). 'Eigen codering dus veilig' is al helemaal een reden om gillend weg te rennen.

Dus een hash is wel degelijk in bepaalde gevallen te herleiden naar de oorspronkelijke waarde.

Je kan ook een input vinden die leidt tot dezelfde hash, oftewel een collision. Je weet niet of het dezelfde input was, maar dat maakt in het geval van passwords niet uit: dezelfde hash = binnen.

Verwijderd schreef op dinsdag 20 september 2016 @ 10:17:

[...]

Welke extra laag beveiliging zou een USB-dongle toevoegen?

Dat zijn Hardware Security Modules (heel duur of betaalbaar) en die zie je vooral bij banken en certificate authorities om cryptografische berekeningen te offloaden naar een vertrouwd/hardened/gecertificeerd stuk hardware. Keymateriaal verlaat een HSM nooit in plaintext vorm. Het is hier niet van toepassing.

'Eigen codering dus veilig' is al helemaal een reden om gillend weg te rennen.

Yup. Dit is geen vertrouwenwekkende reactie. Neem iig geen wachtwoord dat je ergens anders gebruikt. Of het reden voor je is om te stoppen als klant is een vraag die je zelf moet beantwoorden.

Specifiek voor dit geval: ik begrijp dat dit vaak gebeurt bij usenetproviders? Misschien bewust, levert het ze dan geen plausible deniability op? "Iedereen kan het wachtwoord onderscheppen, dus een ander kan NijntjeS23E12.mkv hebben geuploaded met die account!"

Standeman schreef op dinsdag 20 september 2016 @ 09:03:
Daar gaan sowieso al mijn nekharen van overeind staan. Tenzij je een paar jaartjes rond hebt gelopen op de KU Leuven onder de begeleiding van Dhr. Rijmen moet je sowieso ver weg blijven van een zelf gebakken implementatie. Kans dat daar gaten in zitten is ongeveer 100%.

Met eigen codering kan men natuurlijk prima bedoelen dat ze aan hun kant zelf encryptie toepassen met een bestaand algoritme. Dat lijkt me waarschijnlijk dan dat ze zelf een encryptiestandaard hebben proberen uit te vinden.

Standeman schreef op dinsdag 20 september 2016 @ 09:03:
[...]
Daar gaan sowieso al mijn nekharen van overeind staan.

AMEN!

Tenzij je een paar jaartjes rond hebt gelopen op de KU Leuven onder de begeleiding van Dhr. Rijmen moet je sowieso ver weg blijven van een zelf gebakken implementatie. Kans dat daar gaten in zitten is ongeveer 100%.

Er zijn wel meer universiteiten waar goede professoren werkzaam zijn op dat gebied (Erasmus Universiteit Rotterdam, TU Delft).

Maar ja, er is überhaupt 0,0 argumentatie waarom je wachtwoorden wil encrypten ipv hashen. Ik zou er dus voor zorgen dat je je wachtwoord nergens anders gebruikt.

Hier ben ik het wel weer volkomen mee eens.

-

[ Voor 100% gewijzigd door Firefly III op 21-10-2019 09:32 . Reden: Leeg ivm privacy ]

Ik vraag me af waarom de usenet provider geheim moet blijven? Lijkt me toch wel iets wat voor andere tweakers leerzaam is om te weten.

Hier een artikel over manieren waarop je beter niet (en verderop: hoe wel) je wachtwoorden op te slaan:
https://nakedsecurity.sop...r-users-passwords-safely/

Wellicht een idee om dit door te sturen naar de desbetreffende provider?

Het is op zich wel interessant om het simpel te houden en 'gewoon' naar wat de NIST oplegt aan Amerikaanse (overheids)instanties:

quote: https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

The verifier SHALL use approved encryption and SHALL utilize an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and man-in-the-middle attacks.

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP800-132]. The salt value SHALL be a 32 bit (or longer) random value generated by an approved random number generator and is stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

Resistent tegen 'offline attacks' sluit eigenlijk automatisch al encryptie uit. En verder staan er wat aanwijzingen mbt hoe 'zwaar' e.e.a. moet zijn. PBKDF2 is volgens het artikel van Peetz0r trouwens al achterhaald, in de zin dat er krachtigere algoritmes zijn. De NIST houdt het waarschijnlijk bij PBKDF2 omdat die gestandardiseerd is en relatief eenvoudig te implementeren.

Overigens van dezelfde bron als Peetz0r nog een samenvatting van de NIST-regels, maar dat gaat vooral over dat ze niet alleen zijn afgestapt van suffe wachtwoordregels, maar er zelfs actief tegen optreden:
https://nakedsecurity.sop...es-what-you-need-to-know/

[ Voor 5% gewijzigd door ACM op 20-09-2016 13:35 ]

Freee!! schreef op dinsdag 20 september 2016 @ 12:30:
[...]
Er zijn wel meer universiteiten waar goede professoren werkzaam zijn op dat gebied (Erasmus Universiteit Rotterdam, TU Delft).

Als je aan lijstjes gaat doen: In Eindhoven zit ook een erg sterke groep. Voor toegepaste crypto misschien wel de sterkste vakgroep in Europa. Daniel Bernstein zit achter veel moderne technieken, denk aan ed25519, Poly1305 en Salsa20.

ACM schreef op dinsdag 20 september 2016 @ 13:35:
Resistent tegen 'offline attacks' sluit eigenlijk automatisch al encryptie uit. En verder staan er wat aanwijzingen mbt hoe 'zwaar' e.e.a. moet zijn. PBKDF2 is volgens het artikel van Peetz0r trouwens al achterhaald, in de zin dat er krachtigere algoritmes zijn. De NIST houdt het waarschijnlijk bij PBKDF2 omdat die gestandardiseerd is en relatief eenvoudig te implementeren.

Als je er voor zorgt dat de key veilig opgeslagen is dan is encryptie nog steeds een optie. Echter is het gebruik van een (huur) HSM voor wachtwoord opslag niet opportuun.

[ Voor 38% gewijzigd door ANdrode op 20-09-2016 18:44 ]

DexterDee schreef op dinsdag 20 september 2016 @ 11:36:
[...]

Vandaar dat ik in mijn eerdere post ook bcrypt aanhaalde. Mits goed ingezet kan een computer die 1 miljard SHA-256 hashes per seconde kan uitrekenen maar enkele tientallen brypts uitrekenen. En daarmee maak je het brute forcen van een wachtwoord effectief onhaalbaar met de hardware van vandaag.

Je haalt bcrypt en scrypt door elkaar. bcrypt is tegenwoordig ook bijna te doen (hangt met name van het aantal rounds af); scrypt niet.

[ Voor 3% gewijzigd door SKiLLa op 23-09-2016 01:05 ]

SKiLLa schreef op vrijdag 23 september 2016 @ 00:58:
[...]

Je haalt bcrypt en scrypt door elkaar. bcrypt is tegenwoordig ook bijna te doen (hangt met name van het aantal rounds af); scrypt niet.

Nee hoor, ik haal bcrypt en scrypt niet door elkaar. Ik snap het voordeel van scrypt, memory intensief en zeer lastig te paralleliseren. En hoewel scrypt op dit moment de betere papieren heeft, staan bcrypt en scrypt hoe dan ook beiden in een totaal andere ordergrootte qua performance dan bijv. SHA256. Zelfs als je er een FGPA compute cluster tegenaan gooit.

Blind een hashing algoritme implementeren zonder de implicaties en beperkingen te snappen is hoe dan ook nooit een goed idee. Scrypt met een memory footprint van 4mb of minder is minder secure dan bcrypt. En met bcrypt moet je zorgvuldig het aantal rounds vaststellen. Conclusie is dat, mits correct geïmplementeerd, zowel bcrypt als scrypt veilig genoeg zijn voor password storage. Natuurlijk is het allemaal risk versus reward, nucleaire launch codes moet je anders behandelen dan het inloggen op het gastenboek van je blog.

SKiLLa schreef op vrijdag 23 september 2016 @ 00:58:
[...]


Je haalt bcrypt en scrypt door elkaar. bcrypt is tegenwoordig ook bijna te doen (hangt met name van het aantal rounds af); scrypt niet.

Hoe haal je uit dat artikel dat bcrypt "bijna te doen is"? Sowieso is het een artikel van 4 jaar oud, dus dat is in deze wereld al tamelijk verouderd, maar in dat artikel staat juist dat bcrypt het veel beter doet dan eenvoudiger hash algoritmes (zegmaar een factor miljoen keer beter).

DexterDee schreef op vrijdag 23 september 2016 @ 10:22:En hoewel scrypt op dit moment de betere papieren heeft, staan bcrypt en scrypt hoe dan ook beiden in een totaal andere ordergrootte qua performance dan bijv. SHA256. Zelfs als je er een FGPA compute cluster tegenaan gooit.

Als je scrypt en bcrypt vergelijkt met domweg een van de SHA-algoritmes ben je sowieso appels en peren aan het vergelijken. De diverse hash-algoritmes hebben een heel ander doel dan dat.

Zodra je e.o.a. manier van 'key stretching' toepast (wat vziw ook in bcrypt/scrypt gebeurt, vandaar o.a. de iterations of de 'cost'), dan wordt het beter vergelijkbaar. De door de NIST geadviseerde PBKDF2 is ook domweg een key-stretching algoritme rond een SHA-aanroep. Het zit er dik in dat bcrypt en vooral scrypt dan nog steeds wat lastiger te kraken zijn, maar zodra je 10.000x SHA512 (plus nog wat overhead ivm combineren van resultaten) moet uitvoeren zal dat op een FPGA of GPU alsnog ook een stuk pittiger zijn dan wanneer je het maar 1x doet

Er zijn zoveel partijen die wachtwoorden en accounts per mail versturen. Dit is vaak een start (of update) van een account en uitdrukkelijk de bedoeling dat daarna meteen de wachtwoorden gewijzigd worden door een accounthouder. Als men dat nalaat en de account gegevens blijven geldig is dat wel een domme fout. Helaas zie ik nog maar zelden dat dit afgedwongen wordt.

superduper schreef op vrijdag 23 september 2016 @ 12:17:
Er zijn zoveel partijen die wachtwoorden en accounts per mail versturen. Dit is vaak een start (of update) van een account en uitdrukkelijk de bedoeling dat daarna meteen de wachtwoorden gewijzigd worden door een accounthouder. Als men dat nalaat en de account gegevens blijven geldig is dat wel een domme fout. Helaas zie ik nog maar zelden dat dit afgedwongen wordt.

Eenmalig opsturen is geen ramp, mits het een op dat moment nieuw gegenereerd en verplicht te veranderen wachtwoord is. Dat afdwingen is heel eenvoudig... De werkwijze hier op Tweakers is daar een voorbeeld van.

F_J_K schreef op vrijdag 23 september 2016 @ 12:20:
Eenmalig opsturen is geen ramp, mits het een op dat moment nieuw gegenereerd en verplicht te veranderen wachtwoord is. Dat afdwingen is heel eenvoudig... De werkwijze hier op Tweakers is daar een voorbeeld van.

Wij sturen al een aardige tijd geen wachtwoorden meer op. Je weet tenslotte niet over wat voor kanalen een dergelijk wachtwoord gaat. Vaak wordt mail nog onversleuteld rond gestuurd en dat soort mailtjes kunnen ook 'oneindig' in een mailbox blijven zitten.

Kortom, je krijgt een sleutel opgestuurd (of een mailtje dat we geen account bij dat mailadres kennen) en met die sleutel kan je een nieuw wachtwoord invoeren. En die sleutel vervalt aan onze kant vrij snel (er zijn blijkbaar gebruikers die meerdere weken of zelfs maanden nodig hebben om hun mail te lezen).

Bij nieuwe accounts krijg je iets soortgelijks, een sleutel om te bevestigen dat jij en dat e-mailadres bij elkaar horen.

[ Voor 12% gewijzigd door ACM op 23-09-2016 14:26 ]

ACM schreef op vrijdag 23 september 2016 @ 14:22:
[...]

Wij sturen al een aardige tijd geen wachtwoorden meer op. Je weet tenslotte niet over wat voor kanalen een dergelijk wachtwoord gaat. Vaak wordt mail nog onversleuteld rond gestuurd en dat soort mailtjes kunnen ook 'oneindig' in een mailbox blijven zitten.

Kortom, je krijgt een sleutel opgestuurd (of een mailtje dat we geen account bij dat mailadres kennen) en met die sleutel kan je een nieuw wachtwoord invoeren. En die sleutel vervalt aan onze kant vrij snel (er zijn blijkbaar gebruikers die meerdere weken of zelfs maanden nodig hebben om hun mail te lezen).

Bij nieuwe accounts krijg je iets soortgelijks, een sleutel om te bevestigen dat jij en dat e-mailadres bij elkaar horen.

Dat is conceptueel natuurlijk niet echt anders dan een initieel (random) wachtwoord opsturen met de eis dat die bij eerste gebruik wordt aangepast, toch?

ACM schreef op vrijdag 23 september 2016 @ 14:22:
Wij sturen al een aardige tijd geen wachtwoorden meer op. Je weet tenslotte niet over wat voor kanalen een dergelijk wachtwoord gaat. Vaak wordt mail nog onversleuteld rond gestuurd en dat soort mailtjes kunnen ook 'oneindig' in een mailbox blijven zitten.

Pohtato potato: de gegenereerde code is niets anders dan een eenmalig te gebruiken wachtwoord.

Edit: oeps, zie boven.

Orion84 schreef op vrijdag 23 september 2016 @ 14:28:
Dat is conceptueel natuurlijk niet echt anders dan een initieel (random) wachtwoord opsturen met de eis dat die bij eerste gebruik wordt aangepast, toch?

Eens, maar ik denk dat onze manier wel gebruiksvriendelijker is door diverse side-effects.

Zo hoor je een gebruiker ook overal uit te loggen zodra het wachtwoord wordt gewijzigd. Er wordt tenslotte niet voor niets om een nieuw wachtwoord gevraagd, het kan ook zijn dat dat was ivm een vermoeden van misbruik.

Daardoor heeft het direct opsturen van een wachtwoord best wel wat irritant misbruikgedrag: Als ik jouw mailadres weet en ik laat een nieuw wachtwoord naar je opsturen, dan ben je direct (overal) uitgelogd, moet je daarna ontdekken dat er blijkbaar een nieuw wachtwoord is, moet je in je mailbox gaan graven voor je nieuwe wachtwoord en moet je 'm daarna ook nog eens verplicht veranderen.

Als je zelf om een nieuwe vroeg is het een stuk minder erg, maar nog steeds net wat minder handelingen in ons model. De key kan je tenslotte dmv GET-parameters alvast voor-invullen in een formulier, wat met een loginscherm niet zo netjes is (voor dat 'eenmalige wachtwoord'). Daardoor kan je met 1 klik direct terechtkomen op het formulier waar je je wachtwoord kan wijzigen, ipv dat je eerst moet inloggen (copy&paste van het wachtwoord) en daarna je wachtwoord pas kan aanpassen (en daar vaak ook je 'oude' - het net nieuwe - ww weer moet invoeren).

F_J_K schreef op vrijdag 23 september 2016 @ 14:41:
Pohtato potato: de gegenereerde code is niets anders dan een eenmalig te gebruiken wachtwoord.

Edit: oeps, zie boven.

Met als belangrijk verschil dat het eenmalig gegenereerde wachtwoord bij onze variant genegeerd kan worden

[ Voor 10% gewijzigd door ACM op 23-09-2016 14:45 ]

ACM schreef op vrijdag 23 september 2016 @ 14:43:
Eens, maar ik denk dat onze manier wel gebruiksvriendelijker is door diverse side-effects.

Werkt prima.

Orion84 schreef op vrijdag 23 september 2016 @ 10:29:
[...]

Hoe haal je uit dat artikel dat bcrypt "bijna te doen is"? Sowieso is het een artikel van 4 jaar oud, dus dat is in deze wereld al tamelijk verouderd, maar in dat artikel staat juist dat bcrypt het veel beter doet dan eenvoudiger hash algoritmes (zegmaar een factor miljoen keer beter).

Zoals ACM ookal zegt, het blijft appels met peren vergelijken. Maar die 4 jaar oude stats laten al zien dat bcrypt met 1 round ook (toen al) 71K hashes/seconden kan doen. Dat is niet factor miljoenen, maar 100 000+ De meeste libs gebruiken standaard de "$12" rounds en dan kom je inderdaad op luttle hashes per seconden uit, maar als je SHA-256 (of beter PBKDF2) doet, kun je ook gewoon 100K of 200K rounds instellen (ook gangbaar !); effectief kom je dan ook op luttele hashes per secondes uit.

SHA2 en bcrypt zijn natuurlijk voor andere doeleinden en dus doelstellingen ontworpen en zodanig anders ingesteld/'getweaked' (met bcrypt by design meer interne Blowfish rounds dan SHA(2) rounds by design), maar dat wil niet zeggen dat PBKDF2 met HMAC-SHA256 of HMAC-SHA512 perse onveiliger is, ookal zijn de design-eigenschappen anders. De kans dat het 'onveilig' geimplementeerd/geconfigureerd wordt, is uiteraard wel iets groter.