Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Wanneer en waar wordt salten bij Encyption toegepast?

19-04-2020, 09:19 door Anoniem, 6 reacties
Wanneer en waar wordt salten bij Encyption toegepast?
Reacties (6)
19-04-2020, 11:48 door Anoniem
Door Anoniem: Wanneer en waar wordt salten bij Encyption toegepast?

Google is sneller dan hier vragen.

Leren, lezen en zelf doen.
20-04-2020, 09:49 door Anoniem
Door Anoniem:
Door Anoniem: Wanneer en waar wordt salten bij Encyption toegepast?

Google is sneller dan hier vragen.

Leren, lezen en zelf doen.
En als je privacy ook nog belangrijk vindt dan gebruik je niets van Google. Probeer dan eens DuckDuckGo.com of
iets wat je bevalt.

Ik heb een paar links opgezocht, mischien heb je er wat aan.

https://www.byte.nl/kennisbank/onderhoud/gegevens-beveiligen-met-encryptie-en-hashing

https://nl.m.wikipedia.org/wiki/Salt_(cryptografie)
20-04-2020, 11:01 door Anoniem
Een salt wordt gebruikt om het 'bruteforcen' van wachtwoorden tegen te gaan, specifiek helpt het tegen het opstellen van Rainbow tables. Ze staanopgeslagen naast de wachtwoord hash en worden server-side gegerereerd wanneer je een wachtwoord aanmaakt of aanpast.

Als het beheren van wachtwoorden je scenario is, kan je beter kijken naar een Single-Sign On oplossing en los authenticatie systeem (bijv. https://keycloak.org/). Over het algemeen zijn wachtwoord in een dergelijk systeem beter beveiligd dan je zelf kunt bedenken of programmeren (en op termijn bied het de mogelijkheid om over te stappen op WebAuthn als vervanger van wachtwoorden).

Vooral niet denken dat als je een SHA256 van een wachtwoord en salt neemt het opeens allemaal 'veilig' is.
20-04-2020, 14:17 door Anoniem
Door Anoniem: Een salt wordt gebruikt om het 'bruteforcen' van wachtwoorden tegen te gaan, specifiek helpt het tegen het opstellen van Rainbow tables. Ze staanopgeslagen naast de wachtwoord hash en worden server-side gegerereerd wanneer je een wachtwoord aanmaakt of aanpast.

Als het beheren van wachtwoorden je scenario is, kan je beter kijken naar een Single-Sign On oplossing en los authenticatie systeem (bijv. https://keycloak.org/). Over het algemeen zijn wachtwoord in een dergelijk systeem beter beveiligd dan je zelf kunt bedenken of programmeren (en op termijn bied het de mogelijkheid om over te stappen op WebAuthn als vervanger van wachtwoorden).

Vooral niet denken dat als je een SHA256 van een wachtwoord en salt neemt het opeens allemaal 'veilig' is.

Moeten we allemaal niet aan de BCYRPT2 ipv SHA256 tegenwoordig?
26-04-2020, 09:05 door [Account Verwijderd]
Door Anoniem:Moeten we allemaal niet aan de BCYRPT2 ipv SHA256 tegenwoordig?

Scrypt, bcrypt, argon2, het zijn allemaal functies speciaal gemaakt voor het opslaan van wachtwoorden. SHA256 is dat inderdaad niet, vandaar dat ik het benoem. Voor een deel is dat voortschrijdend inzicht, maar je kan je af vragen of dat dit inzicht ook zijn weg gevonden heeft naar bestaande applicaties die er voor kiezen zelf het wachtwoord management te doen. Om te voorkomen dat je deze of andere fouten maakt, is het verstandiger om dit soort zaken over te laten aan een SSO oplossing. Niet dat die koppeling wel zonder problemen te realiseren is, maar het lijkt mij een stuk minder complex. Bovendien ligt bij het eerst volgende datalek niet gelijk je complete lijst met wachtwoorden op straat. Dat is ook wat waard.
26-04-2020, 10:30 door Anoniem
Door iatomory: Scrypt, bcrypt, argon2, het zijn allemaal functies speciaal gemaakt voor het opslaan van wachtwoorden. SHA256 is dat inderdaad niet, vandaar dat ik het benoem. Voor een deel is dat voortschrijdend inzicht, maar je kan je af vragen of dat dit inzicht ook zijn weg gevonden heeft naar bestaande applicaties die er voor kiezen zelf het wachtwoordmanagement te doen.
Je kan je ook van slotenmakers afvragen of ze al dat voortschrijdend inzicht in hun sloten stoppen. Van bijvoorbeeld "slimme sloten" met bluetooth, nfc/rfid, vingerafdruklezers, of vergelijkbare truukerij, zie je zo vaak dat er enorm basale fouten gemaakt worden dat ik m'n vingers er de eerste tien jaar nog niet aan zal branden, en daarna waarschijnlijk nog steeds niet. Wat ik al van verre zag aankomen toen ik voor het eerst van die dingen hoorde dus dat het werkelijk zo'n zooitje is verbaast me niet. En dat zag ik aankomen omdat het duidelijk was dat er met de muziek meegelopen werd, niet omdat er een aanwijsbaar probleem opgelost werd. De houding van de bouwers was hier de tipgever. "Kom laten we hip doen." Dat werkt niet in veiligheidsland.

Om te voorkomen dat je deze of andere fouten maakt, is het verstandiger om dit soort zaken over te laten aan een SSO-oplossing. Niet dat die koppeling wel zonder problemen te realiseren is, maar het lijkt mij een stuk minder complex.
Minder complex is het niet. Er zijn juist meer plekken waarop het mis kan gaan. En je hebt minder controle.

En er zijn niet zoveel "SSO-oplossingen" die geschikt zijn voor "ik weet het ook niet hoor, laat ik het probleem maar aan iemand anders geven".

Bovendien ligt bij het eerst volgende datalek niet gelijk je complete lijst met wachtwoorden op straat. Dat is ook wat waard.
Dat weet je ook bij die "SSO-oplossing" niet zeker.

Je weet wel dat je, bijvoorbeeld, inlogpatronen en persoonsgegevens van je inloggers aan een derde partij weggeeft, en volstrekt afhankelijk bent van dat zij ook geen fouten maken. Dus er hangt een fors prijskaartje aan dat ingebeelde gemak.

Het is heel goed mogelijk om een basale maar acceptabele wachtwoordopslag te bouwen als je weet wat je doet, voor een belangrijk deel door te weten wat al die algoritmes doen en waar ze geschikt voor zijn. Een klein beetje zorgvuldigheid en kennis voorkomt al stomme fouten als nu nog crypt() gebruiken of zelfs helemaal niets.

Dat wil zeggen dat het standaardadvies van cryptografen om vooral niet zelf algoritmes te gaan verzinnen of zelfs te implementeren maar iets te gebruiken dat redelijk goed getest is, wat op zichzelf prima advies is, niet simpelweg door te trekken is naar 'gebruik maar een "SSO-oplossing"'. Ook zo'n "SSO-oplossing" kun je niet veilig inbouwen zonder dat je weet wat je doet. Dus dat is niet de oplossing, het is een optie waar je ook goed van moet weten wat de voors en tegens zijn. Het probleem is dus veeleer dat er nogal vaak securitygevoelige software (en hardware) geknutseld wordt door mensen die daar eigenlijk helemaal niet in de buurt van zouden mogen komen. En daar helpt geen enkele library of externe dienst tegen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.