Archief - Smartphone unieke gegevens ophalen uit de HTTP-headers

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
C

Chickenlal

Legacy Member
Hey,

Is er een mogelijkheid om een uniek gegeven op te halen uit de headers als een persoon mobiel naar je pagina surft?

We zouden graag een alternatief systeem gebruiken voor onze gebruikers het van CMS om eenvoudiger mobiel in te loggen, heb een systeempje ontwikkeld die werkt op basis van het 'pattern lock' van android, waar mensen dus gewoon moeten swipen om hun mobiele wachtwoord (soort van pincode) in te geven. Maar dit is minder veilig natuurlijk.

Daarom zouden we als het mogelijk is willen implementeren dat een account enkel kan inloggen met zijn eigen mobiel toestel. Zou dus een of ander uniek nummer (telefoonnr, sernienummer, ...) moeten kunnen ophalen uit de headers zodat we deze dan kunnen opslaan in de databank. Op deze manier wordt een gsm gelinked aan een account.

Heb al even zitten googlen, maar ben er nog niet wijzer uit geworden.

cliffs:
- Uniek ID van een smartphone (telnr, serienr, ...) ophalen uit de HTTP-headers om een account te linken aan een specifiek toestel.


Thanks in advance!
C

Chickenlal

Legacy Member
Er moet toch iets van een toestel in de headers terecht komen?
d

dJeez

Legacy Member
q-ball_NBK zei:
Er moet toch iets van een toestel in de headers terecht komen?
Klik om te vergroten...
Neen. Je kan dat overigens zelf ook heel makkelijk controleren door met een mobiel toestel naar een script te gaan dat de headers simpelweg dumpt.
C

Chickenlal

Legacy Member
dJeez zei:
Neen. Je kan dat overigens zelf ook heel makkelijk controleren door met een mobiel toestel naar een script te gaan dat de headers simpelweg dumpt.
Klik om te vergroten...

hmm oké, enige link naar zo'n script waarop ik dit kan testen?
C

Chickenlal

Legacy Member
dJeez zei:
Neen. Je kan dat overigens zelf ook heel makkelijk controleren door met een mobiel toestel naar een script te gaan dat de headers simpelweg dumpt.
Klik om te vergroten...

hmm oké, enige link naar zo'n script waarop ik dit kan testen?
C

Chickenlal

Legacy Member
Thanks, als ik het goed begrijp gaan we hier dus niets toestel uniek kunnen ophalen. Dan zet ik mijn zoektocht verder :p
Y

YaMo

Legacy Member
Dat zou ook totaal onveilig zijn, want iedereen kan eender welke http headers versturen die hij wilt, dus zoiets zou heel makkelijk te faken zijn.
C

Chickenlal

Legacy Member
Ja, maar tegen dat mensen (een hacker) zou weten dat het werkt met http headers ipv een username duurt het ook al een tijdje, het zal in alle gevallen al veiliger zijn dan een gebruikersnaam.

Iemand enig idee als ik op een of andere manier een account zou kunnen linken aan een mobiel toestel?
C

Chickenlal

Legacy Member
blackrabbit zei:
Waarom zou dat veiliger zijn?
Klik om te vergroten...

Omdat we willen proberen een account te linken aan een mobile device, dat er enkel mobiel kan ingelogd worden via dat toestel. Maar momenteel vind ik niet echt een mogelijkheid om dit te doen :(

En denk toch dat zoiets veiliger is dan een gebruikersnaam alleen, zal minder snel gehacked worden denk ik omdat ze in eerste instantie niet gaan denken aan een mobiel ID in te geven in de headers, en dan al zeker niet een werkend ID zullen kunnen krijgen.
a

adrianhates

Legacy Member
daar zijn wel andere opties voor hoor.. Alleen is het, zoals hierboven al aangegeven, zeer gemakkelijk om de informatie dat een toestel verstuurt te veranderen / te faken. Waarom zou iets veiliger zijn op zo'n manier als je op die manier zowat "alles" kunt faken ( incl. IP-adres of MAC adres for that matter).

Wat jij wilt bereiken kan even gemakkelijk bereikt worden met een extra urlparameter ?testID2322352=132553356 mee te geven dat voor extra "security" zorgt. Maar dat is security through obscurity en zal u maar in beperkte mate helpen omdat het via-via bemachtigd kan worden ( of via bvb het netwerk te sniffen e.a.).

Het enige dat je extra kan doen is een externe token voorzien zoals ze dat doen bij online banking en al zeker SSL gebruiken! Maar "veilig" filteren op device niveau zal niet gaan voor zover ik weet, maar ik hoor het graag als je het wel vindt :)

ps: post deze vraag een keer duidelijk omschreven op stackoverflow, daar gaat ge sneller meer professioneel advies krijgen.
C

Chickenlal

Legacy Member
Om even te verduidelijken, het is niet zo dat het toestel automatisch ingelogd zal worden, er zal nogsteeds om een paswoord gevraagd worden, maar dit wordt geswiped.

We wouden gewoon af van het feit dat ze hun paswoord moeten intypen op een smartphone, dit is niet altijd even handig voor iedereen. En als we nogsteeds een username zouden moeten laten intypen, dan is het nut ook een beetje verloren. Daarom dat ik op zoek was naar een manier om een username aan een device te koppelen zodat ze enkel een paswoord moeten swipen en zo kunnen inloggen.
b

blackrabbit

Legacy Member
Maar... username kan je toch lokaal opslaan? Ok, dan moet het 1x ingegeven worden, maar so what?
b

bealzebub

Legacy Member
Wat je kan doen is de swipe key (dus het "paswoord" dat ze swipen) gebruiken om username en password in localstorage te decrypten.

Op die manier is de data op de smartphone veilig, aangezien je zonder de sleutel de data wel uit localstorage kan lezen, maar er toch niets mee bent. Da's hoe bijvoorbeeld 1Password het doet: je master password is de sleutel tot het decrypten van je data.

Zo kan je ze éénmalig laten username en password ingeven en die daarna versleutelen met de swipe key.
C

Chickenlal

Legacy Member
Dat klinkt als iets interessant, maar ik ben niet volledig mee.

Hoe sla ik dan de geencrypteerde user/pwd op in de "localstorage" van een smartphone?


Sent from my iPhone using Tapatalk
C

Chickenlal

Legacy Member
Ben een beetje beginnen opzoeken over die html5 local storage en dat ziet er inderdaad wel een vrij goed idee uit. Thanks hiervoor, ga nog ff uitzoeken als dit ondersteund wordt door de meeste browsers enzo en dan proberen te implementeren.
b

bealzebub

Legacy Member
Zolang je geen IE7 of lager moet ondersteunen is het geen probleem, en in mobile bestaat dat dus niet, dus gebruik het maar.
Can I use... Support tables for HTML5, CSS3, etc

Je zal ook nog een clientside encryptie nodig hebben, zoek gewoon eens rond welke je wil gebruiken. Je zou bv. Gibberish AES kunnen nemen.

Dan als de gebruiker de eerste maal je app wil gebruiken:
  • Username
  • Password
  • Data verifiëren op remote server (om te zien of de gegevens juist zijn)
  • Indien correctn, geef uw swipe code in aub, u moet minimum xxx cijfers gebruiken (of whatever)
  • Zorg dat je zowel username/pass als swipe code ergens in Javascript bijhoudt zodat je ze kan gebruiken

Je zou kunnen een JS object maken in de zin van:

Code: 
{
   'username': 'jan.met.de.pet',
   'password': 'iets-secure'
}

Daarop doe je JSON.stringify() en dan encrypt je die string met het swipe paswoord van de gebruiker. Het resultaat daarvan sla je op in een localstorage key.

Code: 
localStorage.setItem("encrypted-login", encryptedJSONData)

Doordat de sleutel om die encrypted-login te decrypten iets is wat de gebruiker ingeeft is die data wel behoorlijk veilig (afhankelijk van hoeveel cijfers je swipe code is etc). Het zal een brute force attack natuurlijk niet doorstaan (welke swipe code wel), maar da's in dit geval toch de bedoeling niet.
C

Chickenlal

Legacy Member
Dat lijkt me inderdaad zeer goed! Ga ik vandaag volledig onder de loep nemen en proberen te implementeren op een testsysteem.

Thanks a lot!
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan