C#: Hashing and Salting (het beveiligen van wachtwoorden)

Pagina: 1
Acties:

Onderwerpen

Vraag


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
Beste Tweakenaars,

Voordat ik verder ga, zou ik even kort wat informatie door willen geven:
  • Programmeertaal: C#
  • Programma voor het ontwikkelen van apps: Visual Studio Enterprise 2017
  • Onderwerp: het beveiligen van wachtwoorden in een database
Nu ik een WPF app heb gemaakt, ben ik ook gaan kijken hoe ik wachtwoorden gecodeerd opgeslagen krijg in mijn database. Op het internet heb ik tal van voorbeelden gezien die je kunt gebruiken voor het coderen van de wachtwoorden. Ik heb nu een werkende codering toegepast met SHA-256 hash algoritme en salt. Mijn vraag is nu: kan mijn onderstaande algoritme veiliger of beter? Ik hoor het graag van u.

Function: voor het hashen van het wachtwoord
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public static string Hash(string value)
        {
            // Hashing SHA256 Algorithm
            using (SHA256CryptoServiceProvider SHA256 = new SHA256CryptoServiceProvider())
            {
                // New Character coding UTF8 
                UTF8Encoding UTF8 = new UTF8Encoding();
                
                // Calculate Hash Value and Convert String to byte Array data
                byte[] data = SHA256.ComputeHash(UTF8.GetBytes(value)); 

                // Return SHA256 string into data
                return Convert.ToBase64String(data);
            }
        }

Function: Creating salt
C#:
1
2
3
4
5
6
7
public static String CreateSalt(int size)
        {
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
            var saltBytes = new byte[size];
            rng.GetNonZeroBytes(saltBytes);
            return Convert.ToBase64String(saltBytes);
        }

Registration: code for applying the salt to the password and inserting it into the database
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 1) MySQL-code in C# string
public static string sqlQueryNewUser = "INSERT INTO login (user, pass, salt) VALUES(@User, @Pass, @userSalt)";

// 2) Inserting data
MySqlCommand cmd = new MySqlCommand(SQL.sqlQueryNewUser, SQLDatabase.Connection());
cmd.CommandType = CommandType.Text;
cmd.Parameters.AddWithValue("@User", txtRegUser.Text);

string userSalt = Hashing.Hash(CreateSalt(10));

cmd.Parameters.AddWithValue("@Pass", Hashing.Hash(pwbRegPass.Password + userSalt)); 
cmd.Parameters.AddWithValue("@userSalt", userSalt);

cmd.ExecuteNonQuery();

Function: Retrieving salt from database
C#:
1
2
3
4
5
6
7
8
                // This code is inside a function...
                string userName = txtUserName.Text.Trim();
                string passWord = pwbPassword.Password.Trim();
                string saltQuery = $"SELECT salt FROM login WHERE user = '{userName}'";
                SQL.sqlDataTable = new DataTable();
                SQL.sqlAdapter = new MySqlDataAdapter(saltQuery, SQLDatabase.Connection());
                SQL.sqlAdapter.Fill(SQL.sqlDataTable);
                string userSalt = SQL.sqlDataTable.Rows[0].ItemArray[0].ToString();

Check: Validating password in C# code from database
C#:
1
string sqlQueryLogin = $"SELECT * FROM login WHERE user='{userName}' AND pass='{Hashing.Hash(passWord + userSalt)}'";

[ Voor 11% gewijzigd door umask op 13-06-2019 12:28 ]

Beste antwoord (via umask op 14-06-2019 09:29)


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Waarom gebruik je GetNonZeroBytes i.p.v. GetBytes? Je verlaagt daarmee je entropie (1/256ste per byte weliswaar, maar toch...) ;)

Verder heb je meerdere SQL injections... Gebruik in hemelsnaam Parametrized Queries. Sowieso is de ADO methode die je hier gebruikt vrij outdated. Ik zou zeggen: kijk eens naar Dapper; dat vereenvoudigt je code echt enorm.

Op je vraag of 't beter kan: ja. Kijk eens naar PBKDF2 Rfc2898DeriveBytes in .Net (of bcrypt of scrypt). De tl;dr is dat je nu maar 1 "round" van hashing doet. Wat je wil is vele duizenden "rounds" doen om zo aanvallers (behoorlijk) te vertragen. Verder zie ik niet hoe lang de salt is die je genereert omdat de call naar CreateSalt ontbreekt; maar als die (te) kort is heb je aan een salt ook nagenoeg niets. Edit: Oh, dat voeg je net toe. As expected: véél te korte salt; 10 bytes (80 bits) is echt te weinig. En in je edit gebruik je opeens ook een parameterized query... in dat geval: consistentie is ook belangrijk ;)

Long story short: don't invent your own crypto tenzij je lerende bent / het een stoeiprojectje is.

[ Voor 96% gewijzigd door RobIII op 13-06-2019 13:19 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Alle reacties


Acties:
  • Beste antwoord
  • +7 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Waarom gebruik je GetNonZeroBytes i.p.v. GetBytes? Je verlaagt daarmee je entropie (1/256ste per byte weliswaar, maar toch...) ;)

Verder heb je meerdere SQL injections... Gebruik in hemelsnaam Parametrized Queries. Sowieso is de ADO methode die je hier gebruikt vrij outdated. Ik zou zeggen: kijk eens naar Dapper; dat vereenvoudigt je code echt enorm.

Op je vraag of 't beter kan: ja. Kijk eens naar PBKDF2 Rfc2898DeriveBytes in .Net (of bcrypt of scrypt). De tl;dr is dat je nu maar 1 "round" van hashing doet. Wat je wil is vele duizenden "rounds" doen om zo aanvallers (behoorlijk) te vertragen. Verder zie ik niet hoe lang de salt is die je genereert omdat de call naar CreateSalt ontbreekt; maar als die (te) kort is heb je aan een salt ook nagenoeg niets. Edit: Oh, dat voeg je net toe. As expected: véél te korte salt; 10 bytes (80 bits) is echt te weinig. En in je edit gebruik je opeens ook een parameterized query... in dat geval: consistentie is ook belangrijk ;)

Long story short: don't invent your own crypto tenzij je lerende bent / het een stoeiprojectje is.

[ Voor 96% gewijzigd door RobIII op 13-06-2019 13:19 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Stoelpoot
  • Registratie: September 2012
  • Niet online
Inderdaad wat Rob al zegt, deze code is niet veilig vanwege o.a. bovenstaande redenen. Buiten dat zie ik niet veel mis met de implementatie van je password hashing, behalve dat ik het Salt niet in het hashproces zie terugkomen (oh dat voeg je net toe) en je geen manier hebt getoont om de hash te upgraden als je een nieuwer algo wilt gebruiken.

Verder mis je een hoop sanity checks in de password validation, en als je die klakkeloos in zou bouwen zou je ook nog last kunnen hebben van een Timing Attack.

De theorie achter het hashen en salten lijk je iig wel enigszins te begrijpen, alleen in de praktijk mis je dus nog wat randzaken.

Either way, ik zou je stellig adviseren om in productiecode niet zelf je implementatie te bouwen. Dat is iets wat gewoon not done is omdat er een hoop haken en ogen aan zitten.

Als je dit puur schrijft als oefening voor jezelf, ga zo door (zolang het bij een oefening blijft), maar neem sowieso de bovenstaande opmerkingen mee.

offtopic:
En daarnaast is je code nog erge spaghetti-code en zou ik adviseren je in te lezen over decoupling, maar dat is meer algemeen commentaar op je code dan specifiek op de veiligheid van de implementatie


offtopic:
En ik ga mee in de aanbeveling van Dapper! Ik zie dat je idd parametrized queries gebruikt in je edit, dus dat snap je iig wel. Het voordeel aan Dapper is dat je wel de veel simpelere syntax hebt die libraries je kunnen bieden, maar nog steeds grotendeels SQL gebruikt ipv een "echte" ORM.

[ Voor 12% gewijzigd door Stoelpoot op 13-06-2019 12:39 ]


Acties:
  • 0 Henk 'm!

  • Korben
  • Registratie: Januari 2001
  • Laatst online: 13-07 01:53

Korben

() => {};

RobIII schreef op donderdag 13 juni 2019 @ 12:26:
As expected: véél te korte salt; 10 bytes (80 bits) is echt te weinig.
Op die pagina staat wel dát je een langere salt moet gebruiken, maar ik zie niet echt een reden waarom. Het nut van een salt is zorgen dat accounts met hetzelfde wachtwoord niet dezelfde hash hebben, oftewel, het beperken van het nut van een rainbow table. Het voorkomt niet dat mensen een brute force of dictionary attack kunnen doen, dus hoe groot moet een salt dan zijn? PBKDF2 gebruikt maar 8 bytes aan salt, dus 10 bytes aan salt lijkt mij meer dan voldoende.

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Korben schreef op donderdag 13 juni 2019 @ 13:28:
[...]
Op die pagina staat wel dát je een langere salt moet gebruiken, maar ik zie niet echt een reden waarom. Het nut van een salt is zorgen dat accounts met hetzelfde wachtwoord niet dezelfde hash hebben, oftewel, het beperken van het nut van een rainbow table. Het voorkomt niet dat mensen een brute force of dictionary attack kunnen doen, dus hoe groot moet een salt dan zijn? PBKDF2 gebruikt maar 8 bytes aan salt, dus 10 bytes aan salt lijkt mij meer dan voldoende.
Nja, dit is meer een theoretische discussie. Een langere salt is gewoon cryptografisch sterker. Een byte (8 bits) of 4 byte (32 bit) salt is in principe natuurlijk al beter dan geen salt, maar een 128 bit salt is dan weer beter dan een 32 bit salt ;) En de huidige consensus is toch wel 32 of 64 byte (ofwel 256/512 bits).
Korben schreef op donderdag 13 juni 2019 @ 13:28:
PBKDF2 gebruikt maar 8 bytes aan salt, dus 10 bytes aan salt lijkt mij meer dan voldoende.
PBKDF2 doet echter meerdere rounds, TS maar 1 ;) Dat maakt brute-forcen van salts in ieder geval haalbaarder (hoe reëel dat is is vers 2).

Ik legde misschien iets teveel nadruk op een lange(re) salt, maar érgens zit een grens waar je zegt: nu heeft 't geen nut meer om nog meer bits toe te voegen. Die grens ligt, iig wmb, boven de 80 bits. Maar afhankelijk van je eisen kan dat, inderdaad, al (meer dan) voldoende zijn. As a rule of thumb though, zou ik toch 128+ bits aanhouden.

Overigens zie je in de paper die je zelf aanhaalt op pagina 20 (en verder) dat de meeste salts toch 16+ bytes (128+ bits) zijn en dat PBKDF2 eigenlijk de uitzondering is daar. En ik had 't niet specifiek over salts voor PBKDF2 maar salts in z'n algemeenheid.

[ Voor 34% gewijzigd door RobIII op 13-06-2019 13:54 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op donderdag 13 juni 2019 @ 12:26:
Waarom gebruik je GetNonZeroBytes? Je verlaagt daarmee je entropie (1/256ste weliswaar, maar toch...) ;)

Verder heb je meerdere SQL injections... Gebruik in hemelsnaam Parametrized Queries. Sowieso is de ADO methode die je hier gebruikt vrij outdated. Ik zou zeggen: kijk eens naar Dapper; dat vereenvoudigt je code echt enorm.

Op je vraag of 't beter kan: ja. Kijk eens naar PBKDF2.
Dank voor de feedback. Ik ben nog C# aan het leren, daarom dat ik dit topic heb gestart. Ik wil graag weten wat ik beter kan doen

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op donderdag 13 juni 2019 @ 14:43:
Ik ben nog C# aan het leren, daarom dat ik dit topic heb gestart.
Dit staat vrij los van C#; (het (goed) toepassen van) hashing, SQL injection etc. zijn allemaal aardig taal-onafhankelijk ;)

[ Voor 4% gewijzigd door RobIII op 13-06-2019 14:46 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op donderdag 13 juni 2019 @ 14:45:
[...]

Dit staat vrij los van C#; (het (goed) toepassen van) hashing, SQL injection etc. zijn allemaal aardig taal-onafhankelijk ;)
Dat klopt weer wel, die technieken probeer ik (zal ik maar zeggen) ook toe te passen en op de juiste manier, daarom ben ik blij dat u met een aantal dingen bent gekomen, die ik eventueel kan toepassen als dat mij lukt.

[ Voor 45% gewijzigd door umask op 13-06-2019 15:00 ]


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op donderdag 13 juni 2019 @ 12:26:
En in je edit gebruik je opeens ook een parameterized query... in dat geval: consistentie is ook belangrijk ;)
Kunt u een verschil aangeven, want ik zie namelijk niet waar ik wel- en niet die parametrized query heb gebruikt..

Acties:
  • +2 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op donderdag 13 juni 2019 @ 15:14:
[...]


Kunt u een verschil aangeven, want ik zie namelijk niet waar ik wel- en niet die parametrized query heb gebruikt..
Dat kan ik, maar deze vraag geeft aan dat het je nog niet duidelijk is wat 't verschil tussen beiden is, maar nog erger: dat je nog niet (goed) snapt wat een SQL injection is (zie mijn eerdere post voor nog een SQL Injection link). En dan kan ik 't antwoord wel geven, maar ik heb liever dat je 't zélf eens probeert te beantwoorden en beargumenteren en dan geven wij wel aan of 't een beetje klopt wat je zegt ;)

Kijk nog eens goed naar sqlQueryNewUser, saltQuery en sqlQueryLogin en hoe het verschilt in hoe de 'variabelen' in die queries worden ingevuld alvorens de query naar SQL geschoten wordt :) Je gebruikt op de ene plaats string interpolation en op de andere plaats een parameterized query.

Verder: Gebruik a.u.b. de wijzig-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

Afbeeldingslocatie: https://tweakers.net/ext/f/rViZSDpQ5n2TpYCcyrDz83Jf/full.png

[ Voor 55% gewijzigd door RobIII op 13-06-2019 15:24 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op donderdag 13 juni 2019 @ 12:26:
Edit: Oh, dat voeg je net toe. As expected: véél te korte salt; 10 bytes (80 bits) is echt
Wat ik nu heb gedaan is i.p.v. 10 bytes te nemen, heb ik de gegenereerde hash output van het wachtwoord gepakt, dit is dan veel veiliger volgens die ene site toch?
C#:
1
string userSalt = Hashing.Hash(CreateSalt(Hashing.Hash(pwbRegPass.Password).Length));

Acties:
  • 0 Henk 'm!

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Waarom zou je dat zelf doen in plaats van de bestaande crypto libraries gebruiken die dit allemaal voor je afhandelen? Tenzij je later een crypto-specialist wil worden is dit niet iets wat je zelf moet gaan experimenteren.

Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
johnkeates schreef op donderdag 13 juni 2019 @ 15:37:
Waarom zou je dat zelf doen in plaats van de bestaande crypto libraries gebruiken die dit allemaal voor je afhandelen? Tenzij je later een crypto-specialist wil worden is dit niet iets wat je zelf moet gaan experimenteren.
Kunt u iets specifieker zijn met 'Waarom zou je dat zelf doen..' wat wil ik zelf doen? Hashing? Zijn er dan geautomatiseerde manieren om dit voor elkaar te krijgen die veel beter en veiliger zijn?

Acties:
  • 0 Henk 'm!

  • Tranzity
  • Registratie: Januari 2001
  • Niet online
Username/Password string opslaan in een database/applicatie lijkt me sowieso niet handig.
Waarom niet een identity provider gebruiken? (facebook, twitter, microsoft?)

Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
Tranzity schreef op donderdag 13 juni 2019 @ 15:46:
Username/Password string opslaan in een database/applicatie lijkt me sowieso niet handig.
Waarom niet een identity provider gebruiken? (facebook, twitter, microsoft?)
Dan staan die gegevens bij hun weer ... Ik wil graag zelf over de gegevens bezitten..
Waarom stel je dit voor?

[ Voor 3% gewijzigd door umask op 13-06-2019 15:51 ]


Acties:
  • +1 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op donderdag 13 juni 2019 @ 15:33:
[...]

Wat ik nu heb gedaan is i.p.v. 10 bytes te nemen, heb ik de gegenereerde hash output van het wachtwoord gepakt, dit is dan veel veiliger volgens die ene site toch?
C#:
1
string userSalt = Hashing.Hash(CreateSalt(Hashing.Hash(pwbRegPass.Password).Length));
Huh? Nee... je hebt de lengte van het de hash van het wachtwoord genomen. Die is constant... dus ik zie niet waarom je zo moeilijk doet en niet gewoon een constante als 16 gebruikt dan (overigens is de lengte van je hash (een constante) 44 tekens/bytes omdat je base64 van een 32 byte value maakt, dat is 352 bits; eerlijk zeggen: was je je daar van bewust of is dit nou precies zo'n detail dat je over het hoofd ziet waar ik 't over heb en waarom men zegt "don't invent your own crypto"? ;) ). En vervolgens trek je ook nog eens een hash van de salt (waarbij je weer entropie weggooit). Dat zijn al 2 'bugs' in 1 regel code waar jij je vast niet van bewust was ;)
umask schreef op donderdag 13 juni 2019 @ 15:41:
[...]


Kunt u iets specifieker zijn met 'Waarom zou je dat zelf doen..' wat wil ik zelf doen? Hashing? Zijn er dan geautomatiseerde manieren om dit voor elkaar te krijgen die veel beter en veiliger zijn?
Ook hier verwijs ik je weer naar mijn eerste post in dit topic. Dit soort zaken wil je inderdaad niet zelf implementeren, daar zijn talloze libraries en andere reeds uitgevonden wielen voor. Vooral bij cryptografie is het heel, héél makkelijk om een foutje te maken dat grote gevolgen kan hebben. Dus, nogmaals, don't invent your own crypto.
umask schreef op donderdag 13 juni 2019 @ 15:51:
[...]

Dan staan die gegevens bij hun weer ... Ik wil graag zelf over de gegevens bezitten..
Waarom stel je dit voor?
Wélke gegevens wil je bezitten (en waarom)? Je bezit geen wachtwoord (alleen een hash ervan en da's maar goed ook). En die gebruik je alleen maar om te verifiëren of Klaasje ook echt Klaasje is. Dan is een "externe" (of "3rd party") identitty provider inderdaad, in een aantal gevallen, een verdomd goed idee. Allereerst hebben zij hun beveiliging geheid beter voor elkaar dan jij, daarbij hoeven mensen geen extra accounts/wachtwoorden te onthouden, profiteer je automatisch mee van 2FA en andere zaken (wachtwoordherstel enz.) die jij allemaal anders ook nog eens moet gaan liggen implementeren. Het is in niet alle gevallen mogelijk een identity provider als Twitter, FB, Google, whatever te gebruiken om wat voor reden dan ook; maar als het een mogelijkheid is zou ik die zéker overwegen.

[ Voor 41% gewijzigd door RobIII op 13-06-2019 16:19 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Gebruik gewoon een authentication of identity lib, zelfs C# heeft dat gewoon standaard.
Je plempt een storage provider, identity library en wat endpoints bij elkaar en je hebt een end-to-end ondersteunde oplossing waarbij de vendor zelf wel aangeeft wanneer er patches zijn voor nieuw gevonden lekken.

Acties:
  • 0 Henk 'm!

  • edeboeck
  • Registratie: Maart 2005
  • Laatst online: 11-09 13:47

edeboeck

mie noow noooothing ...

umask schreef op donderdag 13 juni 2019 @ 15:41:
[...]


Kunt u iets specifieker zijn met 'Waarom zou je dat zelf doen..' wat wil ik zelf doen? Hashing? Zijn er dan geautomatiseerde manieren om dit voor elkaar te krijgen die veel beter en veiliger zijn?
umask schreef op donderdag 13 juni 2019 @ 15:51:
[...]

Dan staan die gegevens bij hun weer ... Ik wil graag zelf over de gegevens bezitten..
Waarom stel je dit voor?
Eerst en vooral: jouw oefening heeft zeker zin om te leren programmeren en om iets van crypto te leren. Op dat gebied zeker zinvol en dus: doe zo voort!

Waar de opmerkingen hier over gaan, is het geval waarin je dit wilt gebruiken in een "échte" toepassing. Zeker voor een toepassing waarbij de front-end een website is (en er dus gemakkelijk onbekenden/ongewensten bij kunnen), is het belangrijk je security op orde te hebben. Ok, jij gebruikt wel WPF, maar aandacht voor security is steeds zinvol ;-)
De kwaliteit van de meeste libraries en framework is veel beter dan wat je zelf kan maken (zeker als je nog lerende bent).
Wil je dus meer veiligheid, gebruik dan de ingebouwde Identity Provider in .Net... jouw wachtwoorden worden netjes secure opgeslagen, terwijl ze toch bij jou in de DB zelf staan (je kán wel external logins - Microsoft Account, Facebook, Twitter, Google, ... - gebruiken, maar dat hoeft niet).

Acties:
  • 0 Henk 'm!

  • Stoelpoot
  • Registratie: September 2012
  • Niet online
johnkeates schreef op donderdag 13 juni 2019 @ 15:56:
Gebruik gewoon een authentication of identity lib, zelfs C# heeft dat gewoon standaard.
Je plempt een storage provider, identity library en wat endpoints bij elkaar en je hebt een end-to-end ondersteunde oplossing waarbij de vendor zelf wel aangeeft wanneer er patches zijn voor nieuw gevonden lekken.
Dat doe je in een productiesysteem, ja. Maar voor de leergierige ontwikkelaar die wat kennis op wil steken, is er niks mis mee om zelf iets in elkaar te flansen om de uitdagingen en principes van zo'n systeem beter te begrijpen. En dat is toevallig wat TS is ;)

Acties:
  • +1 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op donderdag 13 juni 2019 @ 15:51:
[...]
Huh? Nee... je hebt de lengte van het de hash van het wachtwoord genomen. Die is constant... dus ik zie niet waarom je zo moeilijk doet en niet gewoon de constante 16 gebruikt dan.
Ook hier verwijs ik je weer naar mijn eerste post in dit topic. Dit soort zaken wil je inderdaad niet zelf implementeren, daar zijn talloze libraries en andere reeds uitgevonden wielen voor. Vooral bij cryptografie is het heel, héél makkelijk om een foutje te maken dat grote gevolgen kan hebben. Dus, nogmaals, don't invent your own crypto.
Bedankt voor de bron. Ik wil het niet alleen toepassen, maar ik wilde hier ook mee experimenteren, vandaar..
Wélke gegevens wil je bezitten? Je bezit geen wachtwoord (alleen een hash ervan) en da's maar goed ook. En die gebruik je alleen maar om te verifiëren of Klaasje ook echt Klaasje is. Dan is een identitty provider inderdaad, in een aantal gevallen, een verdomd goed idee. Allereerst hebben zij hun beveiliging geheid beter voor elkaar dan jij, daarbij hoeven mensen geen extra accounts/wachtwoorden te onthouden, profiteer je automatisch mee van 2FA en andere zaken (wachtwoordherstel enz.) die jij allemaal anders ook nog eens moet gaan liggen implementeren.
Hmm, nu je een aantal voorbeelden hebt genoemd, heb je me aan het denken gezet.. Daar heb je natuurlijk wel gelijk in..

Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
johnkeates schreef op donderdag 13 juni 2019 @ 15:56:
Gebruik gewoon een authentication of identity lib, zelfs C# heeft dat gewoon standaard.
Je plempt een storage provider, identity library en wat endpoints bij elkaar en je hebt een end-to-end ondersteunde oplossing waarbij de vendor zelf wel aangeeft wanneer er patches zijn voor nieuw gevonden lekken.
Interessant. Kunt u voorbeelden geven voor bijv. authenticatie (gewoon database authenticatie?), identity lib en endpoints? Dit snap ik nog even niet..

Acties:
  • +1 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Stoelpoot schreef op donderdag 13 juni 2019 @ 15:59:
[...]


Dat doe je in een productiesysteem, ja. Maar voor de leergierige ontwikkelaar die wat kennis op wil steken, is er niks mis mee om zelf iets in elkaar te flansen om de uitdagingen en principes van zo'n systeem beter te begrijpen. En dat is toevallig wat TS is ;)
Allemaal heel leuk en aardig, maar als je dan toch "C# aan het leren" bent, begin dan lekker met "Hello world" en de zoveelste TODO-list applicatie. Er geldt nog steeds: je zult je écht beter moeten verdiepen in de materie voordat je een cryptografische zaken begint. Hobby er vooral op los, pruts en knutsel en leer! Zeker! Doen! Goed! Maar doe dat onafhankelijk van het "leren van <taal X>"; beide vliegen in dezelfde klap proberen te slaan is, in dit geval, een disaster waiting to happen™.

Dan @umask:
umask in "C#: Hashing and Salting (het beveiligen van wachtwoorden)"
umask in "C#: Hashing and Salting (het beveiligen van wachtwoorden)"

Heb ik je niet nét nog gewezen op dubbelposten? Gebruik de wijzig-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

Afbeeldingslocatie: https://tweakers.net/ext/f/rViZSDpQ5n2TpYCcyrDz83Jf/full.png

Verder:
umask schreef op donderdag 13 juni 2019 @ 16:11:
Kunt u voorbeelden geven voor bijv. authenticatie (gewoon database authenticatie?), identity lib en endpoints? Dit snap ik nog even niet..
Is je Google stuk? Je maakt me niet wijs dat je tussen @johnkeates' reactie (15:56) en de jouwe (16:11) enige noemenswaardige moeite hebt gedaan zélf iets op te zoeken.

[ Voor 40% gewijzigd door RobIII op 13-06-2019 16:21 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • +1 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op donderdag 13 juni 2019 @ 16:13:
[...]

Allemaal heel leuk en aardig, maar als je dan toch "C# aan het leren" bent, begin dan lekker met "Hello world" en de zoveelste TODO-list applicatie. Er geldt nog steeds: je zult je écht beter moeten verdiepen in de materie voordat je een cryptografische zaken begint. Hobby er vooral op los, pruts en knutsel en leer! Zeker! Doen! Goed! Maar doe dat onafhankelijk van het "leren van <taal X>"; beide vliegen in dezelfde klap proberen te slaan is, in dit geval, een disaster waiting to happen™.
Oké, dan probeer ik C# in zijn geheel beter te snappen voordat ik me bezig ga houden met cryptografie..
Dan @umask:
umask in "C#: Hashing and Salting (het beveiligen van wachtwoorden)"
umask in "C#: Hashing and Salting (het beveiligen van wachtwoorden)"

Heb ik je niet nét nog gewezen op dubbelposten? Gebruik de wijzig-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:


Verder:
Sorry hiervoor, ik zal er rekening mee proberen te houden de volgende keer..
Is je Google stuk? Je maakt me niet wijs dat je tussen @johnkeates' reactie (15:56) en de jouwe (16:11) enige noemenswaardige moeite hebt gedaan zélf iets op te zoeken.
Nee, daar heeft u gelijk in, ik had het inderdaad niet na gezocht, omdat ik even bezig was met iets. Ik zal ernaar kijken. Bedankt dat u mij hierop attendeert.

Acties:
  • 0 Henk 'm!

  • Stoelpoot
  • Registratie: September 2012
  • Niet online
RobIII schreef op donderdag 13 juni 2019 @ 16:13:
[...]

Allemaal heel leuk en aardig, maar als je dan toch "C# aan het leren" bent, begin dan lekker met "Hello world" en de zoveelste TODO-list applicatie. Er geldt nog steeds: je zult je écht beter moeten verdiepen in de materie voordat je een cryptografische zaken begint. Hobby er vooral op los, pruts en knutsel en leer! Zeker! Doen! Goed! Maar doe dat onafhankelijk van het "leren van <taal X>"; beide vliegen in dezelfde klap proberen te slaan is, in dit geval, een disaster waiting to happen™.
Daar kan ik me in vinden, en ik kan je in dit geval ook alleen maar gelijk geven dat dit voor nu misschien te hoog gegrepen is voor TS gezien de laatste paar posts.

Ik reageerde in dit geval puur op de gequotete reactie, die aangaf dat je net zo goed xyz library kan gebruiken in plaats van zelf iets knutselen als oefening / hobbywerk (wat TS al duidelijk had aangegeven). Daar ben ik het dan weer niet mee eens, het hobbyen is (mits op gepast niveau) een uitstekende manier om wat op te steken over technieken als deze. Als je denkt dat de juiste kennis er nog niet is, zeg dat dan ook. Echter in dit geval werd daar niet op ingegaan en was het vooral "als je hier niet je specialisatie van wilt maken, dan hoef je het helemaal niet te leren." En zo te zien aan je reactie zijn we het met elkaar eens dat die leergierigheid, mits passend bij het kennisniveau, juist iets goeds is.

Acties:
  • 0 Henk 'm!

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Hobbyen is natuurlijk prima, maar zelf je securty schrijven is vergelijkbaar met zelf binaire afbeeldingsformaten parsen, ja dat kan, maar of je dat ooit voor productie gaat doen of ooit nuttige kennis hebt die je kan hergebruiken is erg onwaarschijnlijk.

Voor dit soort zaken lijkt het me veel waardevoller om andere dingen goed te doen, zoals data access, defensive coding, koppeling tussen componenten enz.

Het is ook totaan zinloos om te stellen dat je sommige dingen 'alleen in productie' doet, wat is het punt van gescheiden omgevingen dan nog als ze niet 1 op 1 te vergelijken zijn? Wat test je dan nog eigenlijk? Als je iets in prod draait wat in test anders gedaan wordt, dan test je dus eigenlijk helemaal niet wat je in prod doet.

[ Voor 28% gewijzigd door johnkeates op 13-06-2019 19:07 ]


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
Stoelpoot schreef op donderdag 13 juni 2019 @ 12:36:
je geen manier hebt getoont om de hash te upgraden als je een nieuwer algo wilt gebruiken.
Dankjewel voor de tips. Wat bedoel je met een nieuwe manier om je hash up te graden trouwens?
Stoelpoot schreef op donderdag 13 juni 2019 @ 12:36:
offtopic:
En daarnaast is je code nog erge spaghetti-code en zou ik adviseren je in te lezen over decoupling, maar dat is meer algemeen commentaar op je code dan specifiek op de veiligheid van de implementatie
Wat bedoel je met spaghetti code? regel voor regel?

[ Voor 38% gewijzigd door umask op 14-06-2019 09:29 ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op vrijdag 14 juni 2019 @ 08:55:
Dankjewel voor de tips. Wat bedoel je met een nieuwe manier om je hash up te graden trouwens?
Methodes als PHP's password_hash "encoden" in de passwordhash wélke methode (welk hashalgoritme) gebruikt is en hoeveel rounds (ook wel iterations of 'cost' genaamd). Soms nog wel meer. Daardoor kun je, mocht er een probleem ontdekt worden in een hash algoritme in de toekomst, alle passwordhashes bekijken en eventuele probleemgevallen een password reset geven o.i.d.
Je kunt niet 'zomaar' een passwordhash 'upgraden'; daarvoor zal de gebruiker zijn/haar wachtwoord opnieuw moeten invoeren, moet je de oude hash vergelijken en als die in orde is (en je het wachtwoord nog 'in memory' hebt) een nieuwe (verbeterde/andere/"upgraded") hash genereren en de oude overschrijven. Maar dat kun je dus wel 'stilletjes' tijdens een doodnormale login doen; je komt erachter dat er nog een oude hash in je DB staat, je re-hashed (na voorgenoemde controle) met het nieuwe algoritme/cost en slaat die dus op zonder dat de gebruiker er iets van merkt. En zodoende 'upgrade' je langzaamaan bij elke login je hashes naar een nieuwer algoritme/cost.

Zoals je ziet komt er nogal wat bij kijken en dés te meer reden dus om dat uit te besteden aan een identity provider.
umask schreef op vrijdag 14 juni 2019 @ 08:55:
Wat bedoel je met spaghetti code? regel voor regel?
Daar wordt wel op gedoeld ja. Kijk eens naar SOLID. Dat is geen C#-iets maar geldt voor alle OOP talen en is dus zéker iets dat je, als je toch lerende bent, ergens in 't begin van je leertraject wil oppikken. Trust me, hier ga je héél veel aan hebben. Véél meer dan weten hoe een wachtwoord hashen en salten moet ;) :>

Even iets anders:
umask schreef op donderdag 13 juni 2019 @ 12:16:
Voordat ik verder ga, zou ik even kort wat informatie door willen geven:
  • Programma voor het ontwikkelen van apps: Visual Studio Enterprise 2017
Je weet dat er een gratis Community Edition is die gratis is i.p.v. deze wel héle dure oplossing? ;) Zéker als je nog lerende bent heb je aan de CE méér dan voldoende en hoef je niet met illegale software te werken ;) O-)

[ Voor 24% gewijzigd door RobIII op 14-06-2019 10:29 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op vrijdag 14 juni 2019 @ 10:16:
[...]

Zoals je ziet komt er nogal wat bij kijken en dés te meer reden dus om dat uit te besteden aan een identity provider.
Inderdaad. Ik ben al bezig om dit toe te passen in mijn app, omdat dit zoals jullie ook al adviseren gewoon beter en veiliger is.
Daar wordt wel op gedoeld ja. Kijk eens naar SOLID. Dat is geen C#-iets maar geldt voor alle OOP talen en is dus zéker iets dat je, als je toch lerende bent, ergens in 't begin van je leertraject wil oppikken. Trust me, hier ga je héél veel aan hebben. Véél meer dan weten hoe een wachtwoord hashen en salten moet ;) :>
Ik zal ernaar kijken, dankjewel.
Je weet dat er een gratis Community Edition is die gratis is i.p.v. deze wel héle dure oplossing? ;) Zéker als je nog lerende bent heb je aan de CE méér dan voldoende en hoef je niet met illegale software te werken ;) O-)
Lol, bedankt :F Over het hoofd gezien of zo..
RobIII schreef op donderdag 13 juni 2019 @ 15:51:
Huh? Nee... je hebt de lengte van het de hash van het wachtwoord genomen. Die is constant... dus ik zie niet waarom je zo moeilijk doet en niet gewoon een constante als 16 gebruikt dan (overigens is de lengte van je hash (een constante) 44 tekens/bytes omdat je base64 van een 32 byte value maakt, dat is 352 bits; eerlijk zeggen: was je je daar van bewust of is dit nou precies zo'n detail dat je over het hoofd ziet waar ik 't over heb en waarom men zegt "don't invent your own crypto"? ;) ). En vervolgens trek je ook nog eens een hash van de salt (waarbij je weer entropie weggooit). Dat zijn al 2 'bugs' in 1 regel code waar jij je vast niet van bewust was ;)
Hoe bedoel je dat ik een hash van de salt trek? Wat stel je dan voor dat ik doe eigenlijk..
De code die ik dus gebruikte was:
C#:
1
Hashing.Hash(pwbRegPass.Password + userSalt)

Is het dan dus beter om het op deze manier te doen? Dus dat ik de salt gewoon buiten de hash eraan toevoeg?
C#:
1
Hashing.Hash(pwbRegPass.Password) + userSalt
overigens is de lengte van je hash (een constante) 44 tekens/bytes omdat je base64 van een 32 byte value maakt, dat is 352 bits
Hoe weet u dat de lengte 44 tekens lang is? Hoe bent u hierachter gekomen zeg maar? Door de hash output te genereren? En hoe maak ik van de base64 een 32 byte? Waar staat dat eigenlijk?

[ Voor 69% gewijzigd door umask op 14-06-2019 12:31 ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op vrijdag 14 juni 2019 @ 12:14:
Hoe bedoel je dat ik een hash van de salt trek?
Je doet/deed:

string userSalt = Hashing.Hash(CreateSalt(Hashing.Hash(pwbRegPass.Password).Length));

En dat is waar ik op reageerde. Je trekt een hash van de salt op de rode plek ;)
umask schreef op vrijdag 14 juni 2019 @ 12:14:
Wat stel je dan voor dat ik doe eigenlijk..
Het uitbesteden aan een library, zoals gezegd ;) En als je er op staat zelf door te gaan: dat je je héél veel beter in de materie verdiept.

Die regel had er, om even in jouw stramien te blijven, ongeveer zo uit moeten zien:

string userSalt = Base64Encode(CreateSalt(16))

Maar er is een reden waarom we 't blijven afraden zelf hier mee door te gaan ;) En bovenstaand is dan ook zéker niet "dé" oplossing.
umask schreef op vrijdag 14 juni 2019 @ 12:14:
De code die ik dus gebruikte was:
C#:
1
Hashing.Hash(pwbRegPass.Password + userSalt)

Is het dan dus beter om het op deze manier te doen? Dus dat ik de salt gewoon buiten de hash eraan toevoeg?
C#:
1
Hashing.Hash(pwbRegPass.Password) + userSalt
Nee. De eerste methode is goed, maar zoals ik al aangaf, ik reageerde dus op iets anders ;)
umask schreef op vrijdag 14 juni 2019 @ 12:14:
Hoe weet u dat de lengte 44 tekens lang is? Hoe bent u hierachter gekomen zeg maar? Door de hash output te genereren?
Omdat ik weet hoe Base64 werkt ;) Je genereert een constant aantal bytes (32) en dat wordt door Base64 weer in een constant aantal karakters encoded. Base64 is een 6 bits per karakter encoding (ofwel ⅓ 'overhead'). Daar komt nog wat padding bij en dan kom je op 44 tekens (base64 lengte is altijd een meervoud van 4mits je padding gebruikt). 32 * 1⅓ = 42.6, afronden naar eerstvolgende meervoud van 4 geeft 44. En dat dubbelcheck je dan even voordat je 't post :P
umask schreef op vrijdag 14 juni 2019 @ 12:14:
En hoe maak ik van de base64 een 32 byte?
Door 't niet te encoden in the first place 8)7 Of door 't te Base64-decoden; maar dan ben je dus dubbel werk aan 't doen: eerst encoden om 't daarna weer te decoden :X
umask schreef op vrijdag 14 juni 2019 @ 12:14:
Hoe weet u dat [...]
Waar staat dat eigenlijk?
Verwacht je nu 1 linkje waar dit allemaal staat uitgelegd? Dit topic gaat over een heleboel verschillende zaken over een heel breed onderwerp. Dat is niet zo even met 1 linkje of een simpele reactie in dit topic allemaal uit te leggen. Je spreekt hier met mensen met jarenlange ervaring ;) En jij staat (nog) aan de ingang van een behoorlijk diep konijnenhol ;) :>

[ Voor 26% gewijzigd door RobIII op 14-06-2019 13:43 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op vrijdag 14 juni 2019 @ 12:36:
string userSalt = Hashing.Hash(CreateSalt(Hashing.Hash(pwbRegPass.Password).Length));

En dat is waar ik op reageerde. Je trekt een hash van de salt op de rode plek ;)

Die regel had er, om even in jouw stramien te blijven, ongeveer zo uit moeten zien:

string userSalt = Base64Encode(CreateSalt(16))
Zou bijvoorbeeld de onderstaande code ook goed kunnen zijn (alleen even ter controle, ik ga sowieso een library gebruiken, maar even om te weten zeg maar)
C#:
1
string userSalt = Security.CreateSalt(32); 


PS. ik heb Hashing even aangepast naar Security even om onduidelijkheid te vermijden...

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op vrijdag 14 juni 2019 @ 14:25:
[...]

Zou bijvoorbeeld de onderstaande code ook goed kunnen zijn (alleen even ter controle, ik ga sowieso een library gebruiken, maar even om te weten zeg maar)
C#:
1
string userSalt = Security.CreateSalt(32); 
Er van uitgaande dat de imlpementatie van CreateSalt correct is dan wel ja. Aangenomen dat 32 het 'aantal salt bytes' argument is. Maar dat zijn nogal flinke aannames en daarbij heb ik al minimaal 1 punt van kritiek gegeven op je CreateSalt method. En eigenlijk zeg/vraag je hier dus niets anders dan of
C#:
1
string userSalt = <32 random bytes>
"goed zou kunnen zijn".

...en is je vraag dus eigenlijk vrij... nutteloos ;) Al helemaal omdat je verder (nu) achterwege laat wat je met userSalt doet. For all we know wijzig je 1 regel verderop op de inhoud (al dan niet bewust) of gebruik je de salt op de verkeerde plek of gebruik je de variabele helemaal niet of wat-dan-ook en gaat 't verderop dus alsnog gruwelijk mis. De vraag op zichzelf is nutteloos, de vraag in context van dit topic is iets minder nutteloos omdat we de CreateSalt method ergens in dit topic kunnen vinden maar we zien niet of je sindsdien nog iets veranderd hebt, in welk verband je de userSalt variabele gebruikt enzovoorts. Daar is dus geen sluitend antwoord op te geven. Sorry.
umask schreef op vrijdag 14 juni 2019 @ 14:25:
(alleen even ter controle, ik ga sowieso een library gebruiken, maar even om te weten zeg maar)
Héél eerlijk gezegd zegt mijn Spidey-sense me anders dat je stiekem toch hiermee aan 't doorgaan bent ;) :>

[ Voor 57% gewijzigd door RobIII op 14-06-2019 14:46 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op vrijdag 14 juni 2019 @ 14:31:
[...]
Héél eerlijk gezegd zegt mijn Spidey-sense me anders dat je stiekem toch hiermee aan 't doorgaan bent ;) :>
Ja, ik ben zeker door aan het gaan met experimenteren LOL .. ik wil erachter komen wat er precies gebeurd en hoe het ongeveer werkt.. Ik ga het niet gebruiken en zal ik zeker jullie adviezen opvolgen, daarom waardeer alle hulp heel erg. ;) :>

Nee, even serieus. @RobIII het is toch niet erg, dat mensen zoals ik, met dingen gaan experimenteren? Ik ben gewoon nieuwsgierig hoe bepaalde dingen in elkaar steken..

[ Voor 71% gewijzigd door umask op 16-06-2019 21:04 ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
umask schreef op vrijdag 14 juni 2019 @ 14:47:
Nee, even serieus. @RobIII het is toch niet erg, dat mensen zoals ik, met dingen gaan experimenteren? Ik ben gewoon nieuwsgierig hoe bepaalde dingen in elkaar steken..
Dat heb ik eerder al aangegeven ;) Én een taal leren, én cryptografie oppikken tegelijkertijd is niet heel handig. Doe verder vooral wat je niet laten kunt en leuk vindt om te doen, laat niemand je vertellen hoe of wat te werk te gaan. Maar rol in godshemelsnaam je probeersels niet uit naar iets dat (ooit) aan het web hangt. Ik heb inmiddels vaak genoeg naar "don't roll your own crypto" gelinked en dat zou inmiddels aangekomen moeten zijn. Maar als je gewoon wil prutsen en friemelen om te kijken hoe 't werkt: d:)b Leef je uit. Maar probeer dan ook wat bronnen erbij te halen i.p.v. hier elk nieuw (vervolg)vraagje te stellen. Alles wat we je hier kunnen vertellen is meestal de 'gist of it', de "tl;dr", de "vogelvlucht" en alle nuance (en die is zéker bij crypto onmeunig belangrijk) ontbreekt dan. Dus haal dan vooral (reputable) bronnen erbij en lees je in in de materie en ga niet af op wat een stel eppo's op e.o.a. forum je vertellen (waaronder ikzelf dus).

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • umask
  • Registratie: April 2019
  • Laatst online: 21-02-2022
RobIII schreef op zondag 16 juni 2019 @ 21:09:
Dus haal dan vooral (reputable) bronnen erbij en lees je in in de materie en ga niet af op wat een stel eppo's op e.o.a. forum je vertellen (waaronder ikzelf dus).
Dat is goed, maar inderdaad ik rol zoiets natuurlijk nooit echt uit. Het is puur om te oefenen.
Pagina: 1