Nieuws
image

Sloveense universiteit verbiedt script, drop, delete en update in wachtwoorden

maandag 22 januari 2024, 09:53 door Redactie, 23 reacties

Medewerkers en studenten van de Universiteit van Ljubljana die een wachtwoord voor hun digitale identiteit willen aanmaken mogen hiervoor verschillende woorden en karakters niet gebruiken, waaronder script, select, insert, update, delete en drop, alsmede de karkaters --, ', /* en */. Het gaat hier om databasecommando's en karakters waarmee aanvallen zoals cross-site scripting en SQL-injection mogelijk zijn.

De Sloveense universiteit biedt een IDportal voor het aanmaken en inloggen met een digitale identiteit. Met deze identiteit zijn vervolgens allerlei digitale diensten te gebruiken. Meer dan 6.000 medewerkers en 39.000 studenten maken er gebruik van. Het verbod op het gebruik van de commando's en karakters doet denken aan onderstaande bekende XKCD-strip. Het wachtwoordbeleid zorgde ook voor een groot aantal reacties op Hacker News, waarbij veel mensen stellen dat het verbod op de betreffende woorden geen effectieve bescherming tegen SQL-injection is.

Image

Reacties (23)
Reageer met quote
22-01-2024, 10:01 door Anoniem
Het is nog vroeg, maar als er queries uitgevoerd worden op een database met het wachtwoord dan betekent dit dat ze wachtwoorden plain-text opslaan?
Reageer met quote
22-01-2024, 10:08 door Anoniem
Het eerste bericht over SQL injection was in 1998 in Phrack Magazine. Meer dan 25 jaar later zou je verwachten dat deze kwetsbaarheid niet meer voorkomt, toch? Computers zijn te complex voor veel gebruikers, maar blijkbaar ook nog voor veel ICT'ers.
Reageer met quote
22-01-2024, 10:12 door Anoniem
Dit verbod suggereert dat wachtwoorden plaintext in de database worden opgeslagen. :X
Reageer met quote
22-01-2024, 10:31 door Anoniem
Wat ik hierbij dacht in de volgorde waarin de gedachten opkwamen:

1. Ze lossen het op de verkeerde plaats op! Het probleem is dat programmeurs geen parameterized queries toepassen.
2. Maar het kan juist helemaal geen kwaad om bij dingen die fout gaan meerdere hobbels op te werpen en niet alleen maar erop te vertrouwen dat de juiste oplossing goed wordt toegepast. Het moet alleen niet in plaats komen van de juiste oplossing.
3. Wacht even, dit gaat over wachtwoorden. Verwerken ze die in SQL-queries zonder dat ze eerst gehasht worden? Dan slaan ze wachtwoorden dus ongehasht op.

Oeps.
Reageer met quote
22-01-2024, 10:37 door Anoniem
Net zo effectief als het verbieden van een krik in de auto om lekke banden te voorkomen.
Reageer met quote
22-01-2024, 11:00 door Anoniem
Door Anoniem: Het is nog vroeg, maar als er queries uitgevoerd worden op een database met het wachtwoord dan betekent dit dat ze wachtwoorden plain-text opslaan?
Nee
Reageer met quote
22-01-2024, 11:01 door Anoniem
Ongetwijfeld verzonnen door een manager...
Reageer met quote
22-01-2024, 11:02 door Anoniem
Door Anoniem: Dit verbod suggereert dat wachtwoorden plaintext in de database worden opgeslagen. :X
Nee hoor, het suggereert dat de applicatie ingegeven woorden één-op-één als parameters van standaard queries zou kunnen doorgeven aan de onderliggende SQL database
Reageer met quote
22-01-2024, 11:25 door Anoniem
In Oost-Europa zijn ze van de botte-bijl oplossingen.. Het probleem ligt altijd ergens anders, nooit bij henzelf...
Dus niet dat ze wachtwoorden in plain text parsen ipv via hashes, niet dat er geen input filtering plaats vindt, niet dat ze het probleem elders neerleggen... je moet toch een 'sterk' wachtwoord hebben?
Het is erg goed mogelijk dat je met "je moet een uniek wachtwoord wat je de afgelopen 20 jaar niet gebruikt hebt, met 20 characters en bijzondere tekens" eens een keer aanloopt tegen een generated passphrase welke zo'n commando bevat.

Is het dan straks een boete krijgen omdat je een wachtwoord via keeppassx hebt gegenereerd?
Reageer met quote
22-01-2024, 11:36 door Anoniem
Door Anoniem: Dit verbod suggereert dat wachtwoorden plaintext in de database worden opgeslagen. :X

SQL injection heeft niks te maken met al dan niet plaintext opslag .

Er is helemaal NIKS mis met een text veld waarvan de inhoud "DROP DATABASE;" is .

Het probleem van SQL injection zit in de verwerking - waarin text strings die geinterpreteerd worden als commando's in plaats van als een text string.

Het klinkt een beetje als een klok-en klepel verhaal. Zowel van de Universiteit, als van de "kenners" die hieruit "afleiden" dat password plain text opgeslagen worden.

Als ik heel positief denk is het (ook) een stukje bescherming van de 'slimmerikken' met zo'n password , die het natuurlijk cut & pasten en dat beslist ook wel eens pasten in het verkeerde window. Of hun eigen password manager om zeep helpen.
Reageer met quote
22-01-2024, 11:55 door Briolet - Bijgewerkt: 22-01-2024, 12:02
script, select, insert, update, delete en drop,

Het komt mij over als onzin om deze wachtwoorden expliciet te verbieden. Het zijn allemaal wachtwoorden van 6 of minder tekens, wat suggereert dat dergelijke onveilig lengtes verder wel toegestaan zijn. Als je de minimum lengte op 8 tekens zou zetten (wat nog steeds erg kort is), dan hoef je deze wachtwoorden niet eens meer te verbieden. Een overdaad aan regels verwart alleen maar.

EDIT: IK lees net de link en zie dat het ook gaat om langere wachtwoorden waar deze worden in geïntegreerd zijn. De lengte is al minimaal 10 tekens.
Reageer met quote
22-01-2024, 13:36 door Anoniem
Door Anoniem:
Door Anoniem: Dit verbod suggereert dat wachtwoorden plaintext in de database worden opgeslagen. :X
Nee hoor, het suggereert dat de applicatie ingegeven woorden één-op-één als parameters van standaard queries zou kunnen doorgeven aan de onderliggende SQL database
Ik zie niet voor me wat je bedoelt. Wat voor standaardquery gebruikt 1:1 ingevoerde woorden van bijvoorbeeld een inlogpagina zonder dat de betekenis van de velden een rol speelt?

Als een wachtwoord gehasht is opgeslagen zie ik geen enkele reden om een ingevoerd wachtwoord ongehasht in welke query dan ook op te nemen. En als men het wachtwoord hasht voor het in een query gebruikt wordt blijft er niets herkenbaars van de genoemde woorden en tekens over zodat er ook geen risico op SQL-injectie is.
Reageer met quote
22-01-2024, 13:59 door Anoniem
Heel goed om dit te verbieden. Alleen al omdat woorden niet random zijn en dus makkelijker te raden en daardoor ook makkelijker te kraken.
Reageer met quote
22-01-2024, 14:32 door Anoniem
Door Anoniem: Heel goed om dit te verbieden. Alleen al omdat woorden niet random zijn en dus makkelijker te raden en daardoor ook makkelijker te kraken.

Geen enkel woord is random. :P Daarom is het een woord.
Reageer met quote
22-01-2024, 14:33 door musiman
Door Anoniem: Het is nog vroeg, maar als er queries uitgevoerd worden op een database met het wachtwoord dan betekent dit dat ze wachtwoorden plain-text opslaan?

Uhhh... nee?

Wanneer iemand zijn/haar wachtwoord wijzigt, kan het systeem op dat moment aangeven dat bepaalde termen niet mogen. Dit kun je bijvoorbeeld in Microsoft Entra ID instellen. Zo heb ik voor onze omgeving een aantal woorden opgegeven die niet gebruikt mogen worden. Denk hierbij aan de maanden, weekdagen, naam van het bedrijf, etc.
Wanneer je zoiets implementeert, dien je er wel voor te zorgen dat de medewerkers weten welke woorden niet toegestaan zijn in een wachtwoord, want ze krijgen bij het gebruik van zo'n wachtwoord enkel te zien dat het wachtwoord "weak" is... ook al hebben ze een zin/passphrase met 40 karakters of zo.
Reageer met quote
22-01-2024, 14:41 door Anoniem
Door Anoniem:
Door Anoniem: Het is nog vroeg, maar als er queries uitgevoerd worden op een database met het wachtwoord dan betekent dit dat ze wachtwoorden plain-text opslaan?
Nee

Wat nee? Er worden toch plaintext wachtwoorden in queries gestopt anders krijg je dit soort meuk toch niet? Dat de queries niet goed verwerkt worden daargelaten.
Reageer met quote
22-01-2024, 14:46 door Anoniem
Door musiman:
Door Anoniem: Het is nog vroeg, maar als er queries uitgevoerd worden op een database met het wachtwoord dan betekent dit dat ze wachtwoorden plain-text opslaan?

Uhhh... nee?

Wanneer iemand zijn/haar wachtwoord wijzigt, kan het systeem op dat moment aangeven dat bepaalde termen niet mogen. Dit kun je bijvoorbeeld in Microsoft Entra ID instellen. Zo heb ik voor onze omgeving een aantal woorden opgegeven die niet gebruikt mogen worden. Denk hierbij aan de maanden, weekdagen, naam van het bedrijf, etc.
Wanneer je zoiets implementeert, dien je er wel voor te zorgen dat de medewerkers weten welke woorden niet toegestaan zijn in een wachtwoord, want ze krijgen bij het gebruik van zo'n wachtwoord enkel te zien dat het wachtwoord "weak" is... ook al hebben ze een zin/passphrase met 40 karakters of zo.

Dat mag je dan wel zo doen, maar dat sluit het niet uit.
Reageer met quote
22-01-2024, 15:00 door Anoniem
Het lijkt er op neer te komen dat er in ieder geval voorheen weinig aandacht aan security is besteed. Dat hoeft niet te betekenen dat de wachtwoorden plain-text worden opgeslagen. Maar aangezien ze wel plain-text in de queries komen te staan
het niet uitsluit dat deze ook plain-text worden opgeslagen.
Reageer met quote
22-01-2024, 16:01 door Anoniem
Ik ben gelukkig niet de eerste, maar het heeft niet te maken met hoe het wordt opgeslagen of dit een probleem is, maar hoe het wordt verwerkt. Ook zijn de mensen die een ww policy opstellen niet de programmeurs van de software waarin deze wordt ingevoerd. Op deze manier zorgen ze ervoor dat ze niet hoeven te vertrouwen op sanitation. Laat onverlet dat je niet helemaal goed snik ben als je je eigen Identity Provider gaat bouwen waardoor dit een gevaar kan zijn, maar goed.
Reageer met quote
22-01-2024, 16:54 door Anoniem
Door Anoniem: In Oost-Europa zijn ze van de botte-bijl oplossingen.. Het probleem ligt altijd ergens anders, nooit bij henzelf...

Sinds wanneer ligt Slovenië in Oost-Europa?
Reageer met quote
22-01-2024, 21:24 door Anoniem
Door Anoniem:
Door Anoniem: In Oost-Europa zijn ze van de botte-bijl oplossingen.. Het probleem ligt altijd ergens anders, nooit bij henzelf...

Sinds wanneer ligt Slovenië in Oost-Europa?
Alles ten oosten van de lijn Berlijn-Rome is voor mij Oost-Europa.
Reageer met quote
23-01-2024, 09:11 door Anoniem
Door Anoniem: Het eerste bericht over SQL injection was in 1998 in Phrack Magazine. Meer dan 25 jaar later zou je verwachten dat deze kwetsbaarheid niet meer voorkomt, toch? Computers zijn te complex voor veel gebruikers, maar blijkbaar ook nog voor veel ICT'ers.
Het hangt er maar net vanaf wie je het ontwerp laat doen. Iemand met gedegen kennis en ervaring MET security als een van de eisen van het ontwerp.
Of een trainee die voordien iets anders geleerd heeft en op het leaseauto aanbod inging.

De laatsten zijn wat ruimer voor handen en goedkoper.
Reageer met quote
23-01-2024, 09:50 door Korund
Door Anoniem: Het is nog vroeg, maar als er queries uitgevoerd worden op een database met het wachtwoord dan betekent dit dat ze wachtwoorden plain-text opslaan?
Nee, vlak voordat het plain-text wachtwoord gehasht wordt t.b.v. opslag in de database, kan het gecontroleerd worden. Je hebt dan ook de mogelijkheid om het te scannen op minimaal aantal cijfers, hoofdletters, leestekens, enzovoort.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Zoeken
search
Certified Secure