[SQL] Automatisch eerst beschikbare record invoegen

[LeonM]

De titel klinkt wat raar, puur omdat ik geen flauw idee heb hoe ik dit anders moet noemen (als ik dat wel wist, dan had ik waarschijnlijk al een oplossing gevonden )

Ik heb een tabel met daarin onder andere userid's en pincodes. Een record in deze tabel geeft de user eenmalig de mogelijkheid deze pincode te gebruiken. De pincode moet in dit systeem uniek zijn en sinds we 4 cijferige codes gebruiken hebben we dus 10k mogelijke pincodes.

Sinds de pincodes maar eenmalig worden gebruikt door de user, en het aantal mogelijke pincodes beperkt is, wordt een record verwijderd wanneer de user deze heeft gebruikt (Wordt uiteraard wel elders gelogd). Voor de pincodes gebruiken we auto increment (user kan toch niet weten welke user voor/na hem komt).

Dit gaat de eerste 10k keer goed, maar wanneer de pincode de 9999 passeert, moet mijn DB automatisch weer het eerst beschikbare (dus niet in de tabel aanwezige) pincode gaan gebruiken.

Hoe pak ik zo iets aan?

[EddoH]

Een simpele SQL sequence die van 0 tot 9999 loopt?

Aanvulling: met behulp van een stored procedure en de sequence een id kiezen die nog niet in de tabel staat.
Ik weet echter niet of dit best-practice is.

edit: vraag niet helemaal goed begrepen.

[ Voor 67% gewijzigd door EddoH op 21-12-2010 12:18 ]

[sig69]

Gewoon doornummeren en de laatste 4 cijfers pakken?

[LeonM]

sig69 schreef op dinsdag 21 december 2010 @ 12:17:
Gewoon doornummeren en de laatste 4 cijfers pakken?

Kan dat? De pincode moet wel uniek zijn, dus dan krijg je toch het risico dat er een nummer wordt gegenereerd welke al bestaat?

[RobIII]

LeonM schreef op dinsdag 21 december 2010 @ 12:30:
[...]


Kan dat? De pincode moet wel uniek zijn, dus dan krijg je toch het risico dat er een nummer wordt gegenereerd welke al bestaat?

Dan is 't toch juist uniek als je gewoon doornummert? Pak de "mod 10000" van dat nummer et voila. Bij een eventuele select pak je de hoogste pincode (waarmee oude automatisch "vervallen")

[tfx]

RobIII schreef op dinsdag 21 december 2010 @ 12:31:
[...]

Dan is 't toch juist uniek als je gewoon doornummert? Pak de "mod 10000" van dat nummer et voila. Bij een eventuele select pak je de hoogste pincode (waarmee oude automatisch "vervallen")

Als ik het goed begrijp mogen de pincodes zolang ze in de tabel staan niet vervallen. Dus je zou dan eigenlijk de eerste de beste getal willen tussen de 0 en 9999 welke nog niet in tabel staat.

[ Voor 11% gewijzigd door tfx op 21-12-2010 12:38 ]

[LeonM]

RobIII schreef op dinsdag 21 december 2010 @ 12:31:
[...]

Dan is 't toch juist uniek als je gewoon doornummert? Pak de "mod 10000" van dat nummer et voila. Bij een eventuele select pak je de hoogste pincode (waarmee oude automatisch "vervallen")

Ik denk dat mijn SP niet helemaal duidelijk is. Elke pincode tussen de 0 en 9999 mag maar één keer voorkomen. In de oplossing van sig69 zal 1 en 10001 dezelfde pincode opleveren, wat dus niet mag.

Ik was nog niet bekend met sequences, maar dit lijkt al de helft van mijn probleem op te lossen. Nu nog de andere helft: hoe bepaal ik de eerste (laagste) pincode die NIET voorkomt in een tabel?

[sig69]

tfx schreef op dinsdag 21 december 2010 @ 12:35:
[...]


Als ik het goed begrijp mogen de pincodes zolang ze in de tabel staan niet vervallen. Dus je zou dan eigenlijk de eerste de beste getal willen tussen de 0 en 9999 welke nog niet in tabel staat.

Als hij nog in de tabel staat, is hij niet vervallen, dus kan je'm gebruiken, dus heb je ook geen nieuwe nodig

LeonM schreef op dinsdag 21 december 2010 @ 12:38:
[...]


Ik denk dat mijn SP niet helemaal duidelijk is. Elke pincode tussen de 0 en 9999 mag maar één keer voorkomen. In de oplossing van sig69 zal 1 en 10001 dezelfde pincode opleveren, wat dus niet mag.

Ik was nog niet bekend met sequences, maar dit lijkt al de helft van mijn probleem op te lossen. Nu nog de andere helft: hoe bepaal ik de eerste (laagste) pincode die NIET voorkomt in een tabel?

Maak een tabel met alle mogelijke pincodes (1-9999). dan kom je met een left join en MIN() een heel eind denk

[ Voor 100% gewijzigd door sig69 op 21-12-2010 12:41 ]

[YopY]

Je kunt ook een random 4-cijferig getal genereren zodra een gebruiker geregistreerd wordt, of één per user genereren.

En 'sinds de pincodes...' is verengelst neerlandsch, van 'since', maar in het Neerlandsch is dat dus 'omdat' . * YopY maakt zich daar waarschijnlijk ook regelmatig schuldig aan.

[tfx]

LeonM schreef op dinsdag 21 december 2010 @ 12:38:
[...]


Ik denk dat mijn SP niet helemaal duidelijk is. Elke pincode tussen de 0 en 9999 mag maar één keer voorkomen. In de oplossing van sig69 zal 1 en 10001 dezelfde pincode opleveren, wat dus niet mag.

Ik was nog niet bekend met sequences, maar dit lijkt al de helft van mijn probleem op te lossen. Nu nog de andere helft: hoe bepaal ik de eerste (laagste) pincode die NIET voorkomt in een tabel?

Ben ook niet bekend met sequences, maar het zou zoiets moeten zijn:
select min(pincode) from table where pincode not in (sequence)

Maar als ik zo kijk, werken sequences niet op die manier. Je hebt dan een hulptabel nodig, zoals sig69 dat vermeld waarin de pincodes in staan.

[ Voor 9% gewijzigd door tfx op 21-12-2010 12:49 ]

[LeonM]

sig69 schreef op dinsdag 21 december 2010 @ 12:39:
[...]

Als hij nog in de tabel staat, is hij niet vervallen, dus kan je'm gebruiken, dus heb je ook geen nieuwe nodig

Als hij nog in de tabel staat dan is deze inderdaad nog niet vervallen, dus mag je deze waarde bij een insert juist niet gebruiken. Het gaat mij om het automatisch toekennen van een nog niet bestaande (of eerder vervallen) pincode aan een nieuw record.

tfx schreef op dinsdag 21 december 2010 @ 12:40:
[...]


Ben ook niet bekend met sequences, maar het zou zoiets moeten zijn:
select min(pincode) from table where pincode not in (sequence)

Maar als ik zo kijk, werken sequences niet op die manier.

Dat ziet er veel belovend uit. Dat ga ik even proberen.

edit:
Bah, MySQL lijkt geen sequnces te ondersteunen.

[ Voor 26% gewijzigd door LeonM op 21-12-2010 12:53 ]

[Reinier]

sig69 schreef op dinsdag 21 december 2010 @ 12:39:
[...]

Maak een tabel met alle mogelijke pincodes (1-9999). dan kom je met een left join en MIN() een heel eind denk

Solved

[Janoz]

Ik vraag me eigenlijk iets af, en dan voornamelijk bij het invoeren van die pincode.

Bij het invoeren, wordt dan enkel de pincode gevraagd, of ook de gebruiker?

Als ja:

Waarom maak je het jezelf zo moeilijk? Een random code genereren is veel simpeler. Ten eerste is er helemaal geen noodzaak om de waarde uniek te houden aangezien de userid al uniek is en ten tweede is een random code een stuk veiliger aangezien de huidige code erg voorspelbaar is (want oplopend)

Als nee:

Dit lijkt me de meest onveilige oplossing die je je maar kunt verzinnen aangezien de pincode niet alleen genoeg is om de handeling te doen, maar ook nog eens enorm voorspelbaar. Zodra ik een pincode opgestuurd krijg kan ik dus redelijk simpel de omliggende codes ook proberen en zo op plekken komen die eigenlijk voor andere gebruikers bedoeld zijn.


Resumerend: Je huidige oplossing is kwalitatief uitermate teleurstellend. Je kunt dan ook beter dat probleem oplossen ipv dit symptoom te bestrijden.

[LeonM]

Janoz schreef op dinsdag 21 december 2010 @ 12:53:
Ik vraag me eigenlijk iets af, en dan voornamelijk bij het invoeren van die pincode.

Bij het invoeren, wordt dan enkel de pincode gevraagd, of ook de gebruiker?

Als ja:

Waarom maak je het jezelf zo moeilijk? Een random code genereren is veel simpeler. Ten eerste is er helemaal geen noodzaak om de waarde uniek te houden aangezien de userid al uniek is en ten tweede is een random code een stuk veiliger aangezien de huidige code erg voorspelbaar is (want oplopend)

Als nee:

Dit lijkt me de meest onveilige oplossing die je je maar kunt verzinnen aangezien de pincode niet alleen genoeg is om de handeling te doen, maar ook nog eens enorm voorspelbaar. Zodra ik een pincode opgestuurd krijg kan ik dus redelijk simpel de omliggende codes ook proberen en zo op plekken komen die eigenlijk voor andere gebruikers bedoeld zijn.


Resumerend: Je huidige oplossing is kwalitatief uitermate teleurstellend. Je kunt dan ook beter dat probleem oplossen ipv dit symptoom te bestrijden.

Goed, ik zal het even wat duidelijker uitleggen.

Users melden zich aan bij ons systeem met een Mifare kaart (welke een UID heeft, welke gekoppeld is aan een user in onze DB).
We willen nu dat users met andere, niet door ons uitgegeven kaarten kunnen inloggen op ons syteem. Denk hierbij bijvoorbeeld aan een OV-chipkaart.

Wij willen een user eenmalig het recht geven in te loggen met een voor ons onbekend pas, bij een door de gebruiker gespecificeerd inlogpunt (staan door heel NL). Om misbruik te voorkomen, moet de user dan wel een pincode invoeren wanneer hij zijn nieuwe pas voor het eerst gebruikt.

De ENIGE manier waarop wij een vreemde pas kunnen identificeren is adv de pincode die de user invoert. Daarom moet deze uniek zijn.

Zodra een login met vreemde pas wordt ontvangen, wordt adv de ingevoerde pincode bepaald welke user dit is geweest, en wordt het nieuwe Mifare UID gekoppeld aan de user, waardoor deze voortaan ook met zijn nieuwe pas, zonder pincode kan inloggen.

edit:
De inlog locatie en een tijdslot zijn vooraf vestgesteld door de gebruiker. Dus mocht een andere kwaadwillende gebruiker misbruik van de situatie willen maken, dan moet hij:
- Weten WAAR iemand een nieuw pas gaat aanmelden
- Weten WAT zijn pincode is
- Weten WANNEER het tijdslot is dat de gebruiker een nieuwe pas mag aanbieden.

Zo kwalitatief uitermate teleurstellend is het ontwerp dus niet, en onveilig lijkt het me ook niet bepaald.

[ Voor 9% gewijzigd door LeonM op 21-12-2010 13:07 ]

[Verwijderd]

LeonM schreef op dinsdag 21 december 2010 @ 13:01:
[...]


Goed, ik zal het even wat duidelijker uitleggen.

Users melden zich aan bij ons systeem met een Mifare kaart (welke een UID heeft, welke gekoppeld is aan een user in onze DB).
We willen nu dat users met andere, niet door ons uitgegeven kaarten kunnen inloggen op ons syteem. Denk hierbij bijvoorbeeld aan een OV-chipkaart.

Wij willen een user eenmalig het recht geven in te loggen met een voor ons onbekend pas, bij een door de gebruiker gespecificeerd inlogpunt (staan door heel NL). Om misbruik te voorkomen, moet de user dan wel een pincode invoeren wanneer hij zijn nieuwe pas voor het eerst gebruikt.

De ENIGE manier waarop wij een vreemde pas kunnen identificeren is adv de pincode die de user invoert. Daarom moet deze uniek zijn.

Zodra een login met vreemde pas wordt ontvangen, wordt adv de ingevoerde pincode bepaald welke user dit is geweest, en wordt het nieuwe Mifare UID gekoppeld aan de user, waardoor deze voortaan ook met zijn nieuwe pas, zonder pincode kan inloggen.

edit:
De inlog locatie en een tijdslot zijn vooraf vestgesteld door de gebruiker. Dus mocht een andere kwaadwillende gebruiker misbruik van de situatie willen maken, dan moet hij:
- Weten WAAR iemand een nieuw pas gaat aanmelden
- Weten WAT zijn pincode is
- Weten WANNEER het tijdslot is dat de gebruiker een nieuwe pas mag aanbieden.

Zo kwalitatief uitermate teleurstellen is het ontwerp dus niet, en onveilig lijkt het me ook niet bepaald.

Wanneer is het af? Dan kunnen de nieuwsposters alvast een bericht klaarzetten voor "<xxxx> eenvoudig te misbruiken". Dit is een typisch voorbeeld van schijnveiligheid. Ik stel voor om te doen wat Janoz voorstelde

[NMe]

LeonM schreef op dinsdag 21 december 2010 @ 13:01:
[...]

De ENIGE manier waarop wij een vreemde pas kunnen identificeren is adv de pincode die de user invoert. Daarom moet deze uniek zijn.

Je weet dat het vervolgens dan wel bijzonder makkelijk is om codes te kraken? Maak dan op zijn minst die random code niet oplopend... En realiseer je goed dat je jezelf voor altijd limiteert aan 10k pincodes (= gebruikers) max. Als je zo bang bent dat bij het bereiken van code 9999 de code 0000 nog steeds niet vrijgegeven is, dan loopt blijkbaar op een gegeven moment je tabel vol...

[ Voor 13% gewijzigd door NMe op 21-12-2010 13:09 ]

[LeonM]

Reinier schreef op dinsdag 21 december 2010 @ 12:49:
[...]


Solved

Zou moeten werken ja, maar ik vind het niet de meest elegante oplossing om overal tabellen met squences te gaan maken. Kan dit niet beter?

[LeonM]

NMe schreef op dinsdag 21 december 2010 @ 13:07:
[...]

Je weet dat het vervolgens dan wel bijzonder makkelijk is om codes te kraken? Maak dan op zijn minst die random code niet oplopend... En realiseer je goed dat je jezelf voor altijd limiteert aan 10k pincodes (= gebruikers) max.

Goed, random kan ook, lijkt mij niet zo'n probleem.

Wanneer de user eenmaal een nieuwe pas heeft aangemeld, dan komt daarmee ook voor hem de mogelijkheid te vervallen dat dit nog een keer kan, en kan de pincode dus worden herbruikt voor een andere user.
De enige limiet is dat we maximaal 10k users dit recht tegelijkertijd kunnen geven, daarom zit er ook nog een verloopdatum op.

Als de user een nieuwe pas heeft ingebracht, of wanneer de verloopdatum is verstreken moet daarom het record worden verwijderd uit de tabel zodat de pincode weer bruikbaar wordt.

Dit brengt mij dus weer op de vraag uit de SP:
Hoe bepaal ik de eerst volgende (evt random) beschikbare (dus niet in de tabel voorkomende) pincode?

[ Voor 18% gewijzigd door LeonM op 21-12-2010 13:12 ]

[Verwijderd]

Overigens is het stellen van dit soort vragen op een publiek forum ook zeker geen goede beveiliging voor je systeem. Met wat (social) engineering weet iemand straks via deze thread zo wat de limitaties van jullie systeem zijn.

[ Voor 3% gewijzigd door Verwijderd op 21-12-2010 13:11 ]

[glashio]

Buiten het oordelen over design

SQL:

SELECT id % 10000

Should do the trick

[Janoz]

LeonM schreef op dinsdag 21 december 2010 @ 13:01:
De ENIGE manier waarop wij een vreemde pas kunnen identificeren is adv de pincode die de user invoert. Daarom moet deze uniek zijn.

Ik had een beetje de hoop dat het het andere voorbeeld was, maar op dit moment schieten mij de tranen een beetje in de ogen.

Kunnen jullie alsjeblieft iemand aantrekken die wel verstand heeft van security ipv maar een beetje aan lopen kloten? Als dit een hobby projectje was geweest was het tot daar aan toe geweest, maar dat jullie werkelijk dergelijke troep durven op te leveren aan een klant (of jullie eigen business model er aan op willen hangen) zou verboden moeten worden.

[NMe]

LeonM schreef op dinsdag 21 december 2010 @ 13:10:
[...]

Goed, random kan ook, lijkt mij niet zo'n probleem.

Wanneer de user eenmaal een nieuwe pas heeft aangemeld, dan komt daarmee ook voor hem de mogelijkheid te vervallen dat dit nog een keer kan, en kan de pincode dus worden herbruikt voor een andere user.
De enige limiet is dat we maximaal 10k users dit recht tegelijkertijd kunnen geven, daarom zit er ook nog een verloopdatum op.

Is die verloopdatum kleiner dan de tijd die het kost om van code 0000 naar 9999 te werken als je sequentieel werkt? In dat geval zit je namelijk een non-probleem op te lossen. Een vrij willekeurig getal selecteren is vrij simpel te bruteforcen, maak een temporary table waarop je queriet met een stored procedure. Simpel loopje om die tijdelijke tabel te vullen met alle waardes van 0 tot 9999, daarop een join doen, where code not in (), order by rand(), klaar.

[MueR]

Als je dan toch met dit systeem wil werken, begin eens met het idee dat je gebruikte codes moet verwijderen te schrappen. Een InUse flag is veel nuttiger. Neem dat maar aan van iemand die betaalsystemen per telefoon (je weet wel, van die gekke inbel/sms codes) heeft ontwikkeld.

[LeonM]

Janoz schreef op dinsdag 21 december 2010 @ 13:13:
[...]

Ik had een beetje de hoop dat het het andere voorbeeld was, maar op dit moment schieten mij de tranen een beetje in de ogen.

Kunnen jullie alsjeblieft iemand aantrekken die wel verstand heeft van security ipv maar een beetje aan lopen kloten? Als dit een hobby projectje was geweest was het tot daar aan toe geweest, maar dat jullie werkelijk dergelijke troep durven op te leveren aan een klant (of jullie eigen business model er aan op willen hangen) zou verboden moeten worden.

Tweakers.net stelt:
Let op:

* Reageer ontopic, plaats geen onzinnige berichten en ga niet flamen of uitlokken (trollen).

Sinds je me nu op persoonlijk niveau begint aan te spreken: ik heb dit systeem niet zo ontworpen, het is zo gespecificeerd. Voor ons is dit een hardware imitatie (van de RFID scanner), en we hebben dus geen andere keus users te identificeren via een 4 cijferige PIN code. Onze klant is op de hoogte van het veiligheidsrisico en aanvaard deze.

Voor alle andere kwesites, brute forcen kan niet (x maal verkeerd invoeren en de reader lockt).

Jammer dat er niet ontopic wordt gereageerd, en alleen maar kwesites worden gesteld over een systeem waar jullie de details niet van weten...

[joppybt]

LeonM schreef op dinsdag 21 december 2010 @ 13:01:
[...]
De ENIGE manier waarop wij een vreemde pas kunnen identificeren is adv de pincode die de user invoert. Daarom moet deze uniek zijn.

edit:
De inlog locatie en een tijdslot zijn vooraf vestgesteld door de gebruiker. Dus mocht een andere kwaadwillende gebruiker misbruik van de situatie willen maken, dan moet hij:
- Weten WAAR iemand een nieuw pas gaat aanmelden
- Weten WAT zijn pincode is
- Weten WANNEER het tijdslot is dat de gebruiker een nieuwe pas mag aanbieden.

Je spreekt jezelf tegen. De pincode is dus niet de enige identificatie maar de combinatie pincode, WAAR en WANNEER. Dat betekent dus dat de pincode op een andere plaats of voor een ander tijdslot best gelijk mag zijn.

[LeonM]

NMe schreef op dinsdag 21 december 2010 @ 13:13:
[...]

Is die verloopdatum kleiner dan de tijd die het kost om van code 0000 naar 9999 te werken als je sequentieel werkt? In dat geval zit je namelijk een non-probleem op te lossen. Een vrij willekeurig getal selecteren is vrij simpel te bruteforcen, maak een temporary table waarop je queriet met een stored procedure. Simpel loopje om die tijdelijke tabel te vullen met alle waardes van 0 tot 9999, daarop een join doen, where code not in (), order by rand(), klaar.

Thanks! Dat is wat ik zocht

MueR schreef op dinsdag 21 december 2010 @ 13:19:
Als je dan toch met dit systeem wil werken, begin eens met het idee dat je gebruikte codes moet verwijderen te schrappen. Een InUse flag is veel nuttiger. Neem dat maar aan van iemand die betaalsystemen per telefoon (je weet wel, van die gekke inbel/sms codes) heeft ontwikkeld.

OK, maar kun je me ook het voordeel uitleggen? Ik ben het met je eens dat je beter geen records kan verwijderen, maar omdat we alle acties ook loggen in een audit tabel, zal het toch alleen maar onnodige duplicaties geven?

[NMe]

LeonM schreef op dinsdag 21 december 2010 @ 13:25:
[...]

Sinds je me nu op persoonlijk niveau begint aan te spreken: ik heb dit systeem niet zo ontworpen, het is zo gespecificeerd. Voor ons is dit een hardware imitatie (van de RFID scanner), en we hebben dus geen andere keus users te identificeren via een 4 cijferige PIN code. Onze klant is op de hoogte van het veiligheidsrisico en aanvaard deze.

Voor alle andere kwesites, brute forcen kan niet (x maal verkeerd invoeren en de reader lockt).

Jammer dat er niet ontopic wordt gereageerd, en alleen maar kwesites worden gesteld over een systeem waar jullie de details niet van weten...

Het is gewoon ontopic, en we hoeven de details niet te weten om te zeggen dat hier onacceptabele beveiligingsrisico's aan zitten. Dat jouw klant ze wel kent en aanvaardt is mooi voor jou, maakt je werk makkelijker. Maar de klant zou ze niet moeten accepteren.

Daarnaast worden er wél gewoon oplossingen aangedragen. Mijn vorige post beschrijft bijvoorbeeld een mogelijke oplossing die ook de meest belangrijke beveiligingsissues uit de weg ruimt.

edit:

Maar dat had je zelf ook al gezien.

LeonM schreef op dinsdag 21 december 2010 @ 13:31:
[...]

OK, maar kun je me ook het voordeel uitleggen? Ik ben het met je eens dat je beter geen records kan verwijderen, maar omdat we alle acties ook loggen in een audit tabel, zal het toch alleen maar onnodige duplicaties geven?

Je elemineert hiermee de noodzaak om een aparte (temp) table met alle mogelijke codes te maken.

[ Voor 17% gewijzigd door NMe op 21-12-2010 13:33 ]

[LeonM]

joppybt schreef op dinsdag 21 december 2010 @ 13:26:
[...]


[...]

Je spreekt jezelf tegen. De pincode is dus niet de enige identificatie maar de combinatie pincode, WAAR en WANNEER. Dat betekent dus dat de pincode op een andere plaats of voor een ander tijdslot best gelijk mag zijn.

Daar heb je inderdaad gelijk in. Op verschillende locaties mag een pincode op hetzelfde tijdstip gelijk zijn.

Neemt niet weg dat ik per locatie nog steeds een unieke pincode moet selecteren.

[CodeCaster]

LeonM schreef op dinsdag 21 december 2010 @ 13:31:
OK, maar kun je me ook het voordeel uitleggen? Ik ben het met je eens dat je beter geen records kan verwijderen, maar omdat we alle acties ook loggen in een audit tabel, zal het toch alleen maar onnodige duplicaties geven?

SQL:

select min(code) from codetabel where inUse='N'

LeonM schreef op dinsdag 21 december 2010 @ 13:34:
[...]

Neemt niet weg dat ik per locatie nog steeds een unieke pincode moet selecteren.

Hoezo dan? Gebruiker van kaart A komt op locatie L met pincode X, en na hem komt de houder van kaart B met dezelfde code X op dezelfde locatie. Die tweede moet toch kaart B alsnog identificeren met de code, je krijgt toch ook het ID van de kaart mee? Al heeft iedereen dezelfde pincode, het kaartnummer verschilt dus de combinatie is uniek.

Als één user één kaart heeft met één code en in gaat loggen op één locatie kun je daar je databasestructuur toch op inrichten?

[ Voor 52% gewijzigd door CodeCaster op 21-12-2010 13:42 ]

[Janoz]

LeonM schreef op dinsdag 21 december 2010 @ 13:25:
Sinds je me nu op persoonlijk niveau begint aan te spreken: ik heb dit systeem niet zo ontworpen, het is zo gespecificeerd. Voor ons is dit een hardware imitatie (van de RFID scanner), en we hebben dus geen andere keus users te identificeren via een 4 cijferige PIN code. Onze klant is op de hoogte van het veiligheidsrisico en aanvaard deze.

Voor alle andere kwesites, brute forcen kan niet (x maal verkeerd invoeren en de reader lockt).

Jammer dat er niet ontopic wordt gereageerd, en alleen maar kwesites worden gesteld over een systeem waar jullie de details niet van weten...

imho is het wel degelijk ontopic. Het gaat hier immers over het pincode systeem. In mijn ervaring zijn 90% van de problemen en moeizame oplossingen terug te voeren op het niet ver genoeg backtracken bij het probleem. Je komt hier op het forum met een probleem, dan kun je natuurlijk niet verwachten dat er alleen maar in een heel klein oplossingsgebiedje gezocht mag worden, zonder dat je duidelijke requirements kunt tonen die die beperking ook opleggen.

Verder ageer ik nogal vaak tegen laks gedrag op het gebied van security, en als je het in je topicstart vervolgens al hebt over ' (user kan toch niet weten welke user voor/na hem komt).' als belangrijke pijler waarop jullie je security baseren dan is het IMHO niet een vergezochte veronderstelling dat jullie de security niet serieus nemen.

[Arie-Kanarie]

Automatisch invoegen gaat denk ik niet lukken, of je moet er auto-increment veld van maken. Dan bepaald MySQL wel welk nummer vrij is. Totdat alle nummers van 1-9999 gebruikt zijn, dan krijg je volgens mij een fout.

Het eerst vrije nummer in kolom bepalen doe ik als volgt:

SQL:

SELECT t1.Nummer + 1
FROM tabel t1
LEFT OUTER JOIN tabel 2 ON (t1.Nummer + 1) = t2.Nummer
WHERE t2.nummer IS NULL

Eerste record van dit resultaat is jou eerste vrij nummer/pincode.

Verder succes met het verwerken van alle kritische (en terechte?) opmerkingen over de (on)veiligheid van je systeem.

[NMe]

Arie-Kanarie: dat lost geen van de problemen van de topicstarter op met betrekking tot het vinden van vrije codes wanneer je een keer rond geweest bent.

[Arie-Kanarie]

NMe schreef op dinsdag 21 december 2010 @ 13:46:
Arie-Kanarie: dat lost geen van de problemen van de topicstarter op met betrekking tot het vinden van vrije codes wanneer je een keer rond geweest bent.

Je bedoelt als alle nummers van 0 t/m 9999 bezet zijn? Klopt, dat is niet helemaal afgevangen, maar dan heb je volgens mij sowieso een probleem.
De query komt uit een systeem waar het ging om een vrij leveranciernummer te bepalen, daar loopt het nummer tot 9999999 (7x 9).
De kans dat iemand 10 miljoen leveranciers heeft lijkt mij sterk, dus daar ben ik verder ook niet mee bezig geweest.

Verder wilde ik ook alleen maar wat bijdragen, heb niet beloofd de oplossing te zijn ;-)

[RobIII]

NMe schreef op dinsdag 21 december 2010 @ 13:46:
Arie-Kanarie: dat lost geen van de problemen van de topicstarter op met betrekking tot het vinden van vrije codes wanneer je een keer rond geweest bent.

^ Met hem; en dat is nog los van allerlei race condities

[ Voor 69% gewijzigd door RobIII op 21-12-2010 13:58 ]

[MueR]

LeonM schreef op dinsdag 21 december 2010 @ 13:31:
OK, maar kun je me ook het voordeel uitleggen? Ik ben het met je eens dat je beter geen records kan verwijderen, maar omdat we alle acties ook loggen in een audit tabel, zal het toch alleen maar onnodige duplicaties geven?

Doordat je alle codes al in je tabel hebt zitten, is het kiezen van een nieuwe code vrij makkelijk. Gewoon een random (of hoogste/laagste) met IsUsed op 0. Daarbij heb je altijd een goed overzicht van de hoeveelheid actieve codes.

Bij een vorige werkgever werkte het systeem ongeveer zoals jij het in eerste instantie wil opzetten, al gebruikte we 6 cijferige codes. De programmeur die het had gemaakt had zaagsel in zn hoofd, waardoor hij ongeveer via deze code codes aan ging maken:

PHP:

do {
  $randomCode = rand(100000, 999999);
  $available = CheckIfInDatabase($randomCode); // returns true if not in database
} while (!$available);

Helaas betekende dit nogal eens wat zoektijd, aangezien hij elke random code ging aflopen. Dit gecombineerd een 24u verloop op codes.. dan kreeg je nogal eens een paar honderd load door infinite loops.

Tegenover

SQL:

SELECT Code FROM Codes WHERE InUse = 0

is de laatste wat performanter

[LeonM]

CodeCaster schreef op dinsdag 21 december 2010 @ 13:34:
[...]

SQL:

select min(code) from codetabel where inUse='N'

[...]

Hoezo dan? Gebruiker van kaart A komt op locatie L met pincode X, en na hem komt de houder van kaart B met dezelfde code X op dezelfde locatie. Die tweede moet toch kaart B alsnog identificeren met de code, je krijgt toch ook het ID van de kaart mee? Al heeft iedereen dezelfde pincode, het kaartnummer verschilt dus de combinatie is uniek.

Als één user één kaart heeft met één code en in gaat loggen op één locatie kun je daar je databasestructuur toch op inrichten?

We weten het kaartnummer niet. Het hele systeem met pincodes is juist, zodat een user zelf een nieuwe pas kan inbrengen in het systeem (maar uiteraard alleen wanneer wij die user daar eenmalig het recht toe geven).

Dus wanneer persoon A en persoon B allebei op dezelfde plek, en binnen hetzelfde tijdslot aanmelden, hoe weet je dan welke nieuwe kaart bij welke user hoort? Daarom moet de code dus uniek zijn.

[Verwijderd]

LeonM schreef op dinsdag 21 december 2010 @ 14:27:
[...]


We weten het kaartnummer niet. Het hele systeem met pincodes is juist, zodat een user zelf een nieuwe pas kan inbrengen in het systeem (maar uiteraard alleen wanneer wij die user daar eenmalig het recht toe geven).

Dus wanneer persoon A en persoon B allebei op dezelfde plek, en binnen hetzelfde tijdslot aanmelden, hoe weet je dan welke nieuwe kaart bij welke user hoort? Daarom moet de code dus uniek zijn.

Misschien een raar idee; maar als de gebruiker zijn kaart toch al bij jullie moet aanmelden om de pincode te krijgen, waarom kan de rest dan niet gelijktijdig afgehandeld worden? Lijkt mij een hoop gedoe en coderen te schelen!

[ Voor 3% gewijzigd door Verwijderd op 21-12-2010 14:32 ]

[LeonM]

Verwijderd schreef op dinsdag 21 december 2010 @ 14:32:
[...]


Misschien een raar idee; maar als de gebruiker zijn kaart toch al bij jullie moet aanmelden om de pincode te krijgen, waarom kan de rest dan niet gelijktijdig afgehandeld worden? Lijkt mij een hoop gedoe en coderen te schelen!

Nee, en user mag lid worden zonder kaart, en moet dus de eerste keer dat hij de dienst wilt gebruiken een pincode invoeren om zijn (voor ons dus onbekende) kaart te activeren.

[Remus]

Op een OV chipkaart zelf staat toch gewoon de kaart ID, waarom kan de gebruiker zich daarmee niet aanmelden?

[Oktopus]

Wat gebeurdt er als persoon B met pincode 2223 een tikfout maakt en 2222 invoert die bij persoon A hoorde? Dan zijn de aanname's dat het precies die persoon was al fout.

[Verwijderd]

LeonM schreef op dinsdag 21 december 2010 @ 14:41:
[...]


Nee, en user mag lid worden zonder kaart, en moet dus de eerste keer dat hij de dienst wilt gebruiken een pincode invoeren om zijn (voor ons dus onbekende) kaart te activeren.

Maar hij kan toch ook gewoon zijn lidmaatschap updaten? Of denk ik nu te simpel... Volgens mij wordt hier een complexe situatie bedacht die vol zit met potentiéle security-problemen die er eigenlijk niet hoeven te zijn. Iemand kan lid zijn zonder kaart, zodra hij een kaart heeft, maakt hij dat bekend bij de supplier. Hij heeft op dat moment de kaart in bezit en dus is de kaart bekend en is dit proces niet nodig.

[CodeCaster]

Verwijderd schreef op dinsdag 21 december 2010 @ 15:30:
[...]


Maar hij kan toch ook gewoon zijn lidmaatschap updaten? Of denk ik nu te simpel... Volgens mij wordt hier een complexe situatie bedacht die vol zit met potentiéle security-problemen die er eigenlijk niet hoeven te zijn. Iemand kan lid zijn zonder kaart, zodra hij een kaart heeft, maakt hij dat bekend bij de supplier. Hij heeft op dat moment de kaart in bezit en dus is de kaart bekend en is dit proces niet nodig.

Ik zie het zo voor me:

code:

Gebruiker maakt bij Supplier een account met relevante gegevens zoals woonplaats
Gebruiker geeft aan nieuwe kaart te willen registreren
Supplier bepaalt op welke paal vlakbij de woonplaats de kaart gekoppeld kan worden 
Supplier genereert pincode 
Supplier slaat pincode bij paalnummer op met een verloopdatum
Supplier geeft pincode, locatie van paal en verloopdatum aan Gebruiker
Gebruiker komt bij paal, haalt pas erlangs, klikt op "Registreren" en vult pincode in
Supplier slaat (indien combinatie van paal en pincode klopt) pasnummer op bij Gebruiker
Pas is nu gekoppeld aan de Gebruiker
???
Profit!

Ik zou in dit geval de Gebruiker bij de registratie toch echt het pasnummer laten intikken in plaats van het gebruiken van een pincode, maar dat is de eeuwige tweestrijd tussen gebruiksgemak en veiligheid.

[ Voor 7% gewijzigd door CodeCaster op 21-12-2010 15:44 ]

[Cloud]

Volgens mij was de OV-chipkaart maar een voorbeeld en moeten andere typen kaarten ook ondersteund worden. Ik denk overigens niet dat het UID (dat kán iets heel anders zijn dan een kaartnummer) van de RFID-chip altijd compleet vermeld staat op de buitenkant van de kaart. En als je de implementatie over alle kaarttypen gelijk wil houden, dan is een UID een beter uitgangspunt dan een door de leverancier bedacht 'kaartnummer'.

Plus qua gebruikersgemak is het natuurlijk wel veel fijner als je gewoon een pincode krijgt die je moet invoeren, i.p.v. complete nummerreeksen door te geven via de telefoon. Zeker als je ten tijde van 'lid worden' nog geen kaart beschikbaar hebt (en je dus wéér contact moet hebben).

Ik hoop dat ik het zo goed begrepen heb.

[ Voor 3% gewijzigd door Cloud op 21-12-2010 15:40 ]

[LeonM]

Remus schreef op dinsdag 21 december 2010 @ 14:58:
Op een OV chipkaart zelf staat toch gewoon de kaart ID, waarom kan de gebruiker zich daarmee niet aanmelden?

Het kaartnummer die op een OV chipkaart staat geprint != het mifare unique ID nummer welke de RFID tag bevat. Sinds users die zelf niet kunnen achterhalen is daar dit systeem voor bedacht.

CodeCaster schreef op dinsdag 21 december 2010 @ 15:35:
[...]

Ik zie het zo voor me:

code:

Gebruiker maakt account op website met relevante gegevens zoals woonplaats
Gebruiker geeft aan nieuwe kaart te willen registreren
Supplier bepaalt op welke paal vlakbij de woonplaats de kaart gekoppeld kan worden 
Supplier genereert pincode 
Supplier slaat pincode bij paalnummer op met een verloopdatum
Supplier geeft pincode, locatie van paal en verloopdatum aan Gebruiker
Gebruiker komt bij paal, haalt pas erlangs, klikt op "Registreren" en vult pincode in
Supplier slaat (indien combinatie van paal en pincode klopt) pasnummer op bij Gebruiker
Pas is nu gekoppeld aan de Gebruiker
???
Profit!

Ik zou in dit geval de Gebruiker bij de registratie toch echt het pasnummer laten intikken in plaats van het gebruiken van een pincode, maar dat is de eeuwige tweestrijd tussen gebruiksgemak en veiligheid.

Dat is inderdaad de volgorde. Zoals ik hierboven beschreef hebben wij niks aan het geprinte pasnummer, dit is nl niet het mifare UID.

Het gebruik van het pasnummer ipv een pincode had wel wat beter geweest, dit had ook die situatie die Oktopus beschreef minder waarschijnlijk gemaakt (maar nogsteeds niet onmogelijk)
Helaas zijn wij gelimiteerd door de hardware waar wij mee moeten werken tot een gebruiker invoer van 4 digits.

[ Voor 7% gewijzigd door LeonM op 21-12-2010 15:56 ]

[Verwijderd]

Nog steeds, als het een intensief gebruikt systeem is (lees: ov studentenkaart drie dagen voor de verplichte invoering) is de kans dat je met een random pincode een pas kunt koppelen behoorlijk groot. Is er geen mogelijkheid om een gebruiker naast een pincode ook een tweede sleutel te geven? Ik ken persoonlijk geen enkel systeem dat werkt met alleen een pincode om toegang tot een systeem te krijgen, ieder systeem dat enkel een code gebruikt voor identificatie dat ik kan gebruikt minstens 8 cijferige nummers.

Dat klant dit risico aanvaard betekent niet dat je het dan maar moet maken, je bedrijf heeft een reputatie hoog te houden dat het goede producten levert, zelfs als klant ook tevreden is met een slecht product.

[D-Raven]

Wellicht dat ik iets niet goed begrijp hoor. Maar waarom word er geen combinatie gemaakt van het Mifare UID en de pincode? Als je de kaart langs de scanner haalt weet je toch welke mifare chip erin zit, dat in combinatie met de pincode van de gebruiker en je hebt altijd een unieke combo.
Dan maakt het ook niet meer uit welke pincode de gebruiker kiest.

Of is een van de limitaties van het systeem dat je het Mifare UID niet kan uitlezen?

edit: ben scheel ofzo

[ Voor 3% gewijzigd door D-Raven op 22-12-2010 12:04 ]

[CodeCaster]

Twee posts boven je wordt verteld dat het kaart-ID bij het aanmaken van het account en het genereren van de pincode nog niet bekend is.

[Cloud]

Hij kent het Mifare UID niet van tevoren en toch moet het UID op een bepaalde plaats en tijd gebruikt kunnen worden. Daar dient de eenmalige pincode voor Zodat het systeem weet welke gebruiker deze nieuwe kaart wil gaan gebruiken.

edit:

@Guldan

Er is een geldigheidsduur, naast de locatie en pincode dus:

LeonM schreef op dinsdag 21 december 2010 @ 13:01:
[...]

Goed, ik zal het even wat duidelijker uitleggen.

edit:
De inlog locatie en een tijdslot zijn vooraf vestgesteld door de gebruiker. Dus mocht een andere kwaadwillende gebruiker misbruik van de situatie willen maken, dan moet hij:
- Weten WAAR iemand een nieuw pas gaat aanmelden
- Weten WAT zijn pincode is
- Weten WANNEER het tijdslot is dat de gebruiker een nieuwe pas mag aanbieden.

[ Voor 56% gewijzigd door Cloud op 22-12-2010 11:35 ]

[Guldan]

@ts wellicht ook handig om ervoor te dat een activerings mogelijkheid icm een pincode een geldigheidsduur heeft. Dwz. u heeft nu 2 dagen om uw kaart te activeren met een bepaalde code.

Ik kon nog niet opmaken of de lengte van de pincode een hardware restrictie is of niet? Want met wat langere cijfers is het gemakkelijker unieke nummers te generen. Is het niet mogelijk om iets dergelijks te maken als het volgende:

1.Gebruiker krijgt via een brief de oproep om zijn kaart te registeren
2.Gebruiker gaat naar website, vult kaartnummer + email adres en codenummer uit de brief in. Daarna krijgt hij een pincode, die wordt gekoppeld aan gebruiker
4.Gebruiker loopt naar apparaat. Typt pincode in en leest kaart
5.Systeem stuurt activatie email naar ingegeven email adres samen met de tijd en eventueel locatie van de lezer.
6.Gebruiker bekijkt mail.. ziet dat locatie en tijd klopt en zegt. Deze gegevens zijn goed.
7.De kaart is geactiveerd

Bovenstaande gaat ervan uit dat er ergens op de kaart een uniek identificatie nummer gedrukt staat. Het verschil met de huidige oplossing is het introduceren van een echt uniek nummer en dus niet een pincode of iets dergelijks die hergebruikt wordt.

[CodeCaster]

Guldan schreef op woensdag 22 december 2010 @ 11:32:
@ts wellicht ook handig om ervoor te dat een activerings mogelijkheid icm een pincode een geldigheidsduur heeft. Dwz. u heeft nu 2 dagen om uw kaart te activeren met een bepaalde code.

LeonM schreef op dinsdag 21 december 2010 @ 13:10:
De enige limiet is dat we maximaal 10k users dit recht tegelijkertijd kunnen geven, daarom zit er ook nog een verloopdatum op.

Als de user een nieuwe pas heeft ingebracht, of wanneer de verloopdatum is verstreken moet daarom het record worden verwijderd uit de tabel zodat de pincode weer bruikbaar wordt.

---

Guldan schreef op woensdag 22 december 2010 @ 11:32:
Ik kon nog niet opmaken of de lengte van de pincode een hardware restrictie is of niet? Want met wat langere cijfers is het gemakkelijker unieke nummers te generen.

LeonM schreef op dinsdag 21 december 2010 @ 13:25:
Voor ons is dit een hardware imitatie (van de RFID scanner), en we hebben dus geen andere keus users te identificeren via een 4 cijferige PIN code. Onze klant is op de hoogte van het veiligheidsrisico en aanvaard deze.

---

Guldan schreef op woensdag 22 december 2010 @ 11:32:
Bovenstaande gaat ervan uit dat er ergens op de kaart een uniek identificatie nummer gedrukt staat. Het verschil met de huidige oplossing is het introduceren van een echt uniek nummer en dus niet een pincode of iets dergelijks die hergebruikt wordt.

LeonM schreef op dinsdag 21 december 2010 @ 15:46:
Dat is inderdaad de volgorde. Zoals ik hierboven beschreef hebben wij niks aan het geprinte pasnummer, dit is nl niet het mifare UID.

Staat dus allemaal al in het topic

[ Voor 37% gewijzigd door CodeCaster op 22-12-2010 11:43 ]

[Guldan]

@hierboven: Ik ben vandaag niet op het scherpst. Bijna vakantie.. maar goed de oplossing die ik voorstelde is nautuurlijk nog steeds relevant.

[Oktopus]

Misschien is het volgende slimmer:

Geef de klanten 2 codes:
De eerste gebruikt de gevraagde functionaliteit om een (tijdelijk) uniek nummer te genereren.
En een tweede willekeurige pincode voor de security.

Systeem constateerd dat een nieuwe UID zich aanmeld. De eerste pincode wordt gebruikt om de controle van de tweede pincode mogelijk te maken. Kloppen deze 2 code's dan kan je de UID en 2e pincode matchen.

[twiFight]

Je kunt het inderdaad misschien combineren met een tweede code: #1 user defined en #2 system defined. Je geeft je (random) gewilde user defined code aan bij het aanmelden (op de website?) en krijgt (alleen met die code) een system defined tweede code terug. Vervolgens moet je bij het paaltje eerst je eigen code invoeren, en daarna de system defined code.

Omdat de user defined code niet incremental is is die ook niet voorspelbaar. En aangezien je de system code alleen te zien krijgt met je eigen code heb je wel een extra laagje beveiliging.

Maar ik weet ook niet wat de limitaties zijn van die paaltjes. Misschien helpt het als je daar wat meer over verteld.

[ajakkes]

Als TS bang is dat op het moment dat 9999 uitgedeeld wordt nummer 0000 nog niet vrij is. Ondanks dat er een tijdslimiet zit op de nummers zal de tijdslimiet korter moeten. Anders is de kans dat het systeem volloopt volgens mij gewoon te groot.

Maar volgens mij is de kans ook vrij groot dat 2 personen op 1 plaats een typefout gaan maken en per ongeluk het volgnummer van de ander gaan intoetsen op deze plaats. Er is namelijk ook een grote kans dat het volgnummer op ongeveer dezelfde locatie wordt aangevraagd. Bijv. door een promotie actie, een familie of vriendengroep.

Maar ik begrijp inmiddels dat je je gebruikers moet identificeren dmv 4 cijfers. Dat dit een beperking is van jou systeem.

In dat geval is de eerder genoemde methode met in use veld iets dat het systeem beter maakt.

Zet 9999 getallen in random volgorde in je tabel. Voeg een inuse veld toe en zoek voor de gebruiker een vrij in use veld.

En bouw een controle in die waarschuwt als 50% en 75% van je pincodes in gebruik zijn. Zodat je kan anticiperen op het leeglopen van beschikbare pincodes.