Olisi tarvetta saada mobiililaitteeseen pelkällä http:llä kirjautuminen, joka on suhkot hyvin suojattu. Käytössä pelkkä JavaScript. Sessionia ei ole tarkoitus käyttää palvelimella, koska sovelluksen käyttöaika voi olla tunteja, ja yhteys voi pätkiä koska vaan tai sitä ei välttämättä ole edes käytössä, kun sovellusta käytetään. Joten käyttäjätunnus ja salasana olisi aina urlissa mukana tietoa lähetettäessä ja noudettaessa.
Https:llä tämä onnistuisi helpommin, mutta sen toimivuus/sopivuus tällä hetkellä epävarmaa kun käytössä on PhoneGap alusta ja testausta ei oikein voi viellä tehdä itse laitteessa iPadissä.
Tarkoitus siis olisi saada suojaus, jossa samalla tunnus yhdistelmällä voidaan kirjautua vain kerran, eli esim md5(kayttajatunnus) + md5(salasana) + md5(muuttuvaAvain) mahdollistaisi kirjautumisen vain kerran aina tietyllä muuttuvalla avaimella.
Jos url olisi siis: http://example.com?tunnus=xxx&salasana=xxx&avain=102 niin 102 avain toimisi vain kerran, eli jos joku näkisi tuon urlin ja koittais käyttää samaa urlia kirjautumiseen se ei toimisi.
Yksi ratkaisu olisi tehdä jokaiselle käyttäjälle oma taulukko, jossa olisi kyseisen käyttäjän kaikki avaimet(pitäisi olla suuri määrä), ja avaimen käytettyään samaa avainta ei voisi käyttää uudestaan. Avain voisi muodostua vaikkapa MD5("joku_suojausteksti" + kayttajatunnus + "joku kasvava numero").
Tällä ratkaisulla joka käyttäjälle tulisi oma taulukko jossa pitäisi olla ainakin 10000 md5 arvoa, ja jota luettaisiin vähän väliä, ja joka voisi olla hidasta. Myös ongelmana on se jos käyttäjä ohjelma hukkaa avaimensa, niin pitäisi etsiä missä ollaan menossa ja se voisi viedä aikaa. No tämän periaatteessa voisi palauttaa serveri käyttäjäkohtaisen tiedoston perusteella.
Niin mietin vaan, että olisiko tähän mahdollisesti jotain paljon parempia ratkaisuja?
Mikset voi tehdä kirjautumista cookieilla? Kirjautumisen voi helposti hoitaa vaikkapa ajaxin avulla, jolla otat yhteyttä erilliseen kirjautumis-skriptiin (PHP). Pitäähän sinulla kuitenkin olla PHP:lle (tai ASP:lle) tuki jos aiot jonkinlaista taulukkosysteemiä tai tietokantaa käyttää.
Sessioidenkaan ei pitäisi kyllä olla ongelma. Kyllä se iPad osaa pitää sen sessiotunnisteen cookieissa vaikka yhteys pätkiikin.
Vaikka käyttäisin sessionia, niin ei se ratkaisisi ongelmaa, koska salasana ja käyttäjänimi silti siirtyisi suojaamattomana http:n ylitse. Ja ne voitaisiin kaapata.
Mutta kyseessä on kuitenkin mobiilisovellus, eli ei pelkkä Web-sivu vaan iPad-laitteeseen asennettava sovellus AppStoresta. Sovellus ei tarvitse internet yhteyttä toimiakseen, mutta internet yhteyttä tarvitaan sillion kuin sovellus lähettää tietoa palvelimelle. Tässä tapauksessa tietona ovat raportit. Sovellus tarvitsee myös internet yhteyttä, kun se lataa data-tiedostot palvelimelta. Eli näihin kahteen asiaan tarvitsee internet yhteyden ja käyttäjän tunnistautumisen, muuten sovelluksen pitää toimia ilman internet yhteyttä ja raportteja pitää pystyä täyttämään ilman internet yhteyttä myös.
Eli jonkunlaisella paketin kaappaus sovelluksella olisi mahdollista nuuskia käyttäjätunnus lähetettävästä tiedosta ja saada tällä haettua tietoa palvelimelta/lähettää tietoa palvelimelle, jos ei suojausta paranna esim. tuolla tapaa miten tuossa ylempänä laitoin.
Käytä HTTP Digest autentikaatiota. Turha keksiä pyörää itse uudestaan.
Softan mukana toimitetaan "AppId", joka on yksillöllinen salainen kiinteä avain.
Lisäksi sovelluksen mukana tulee ensimmäinen "appKey", joka on taas muuttuva ohjelmistokohtainen salainen avain.
Näistä kahdesta muodostuu $updateKey.
$updateKey = sha1($appId . $appKey);
$updateKey lähetetään päivitysen yhteydessä palvelimelle.
http://paivitys.softa.com?updatekey=sdfs90df78rd3422389i34s9efi930fs4dfsfi3
Palvelin löytää kannasta tämän updatekeyn, ja päivittää softan. Sen jälkeen palvelimella luodaan uusi $appKey, joka hashataan palvelimella kyseisen asiakkaan $appId:n kanssa, ja tallennetaan kantaan. Lopuksi asiakkaalle lähetetään uusi Huom hashaamaton appkey, asiakas hashaa uuden appKeyn oman appIdn kanssa, josta taas muodostuu uusi $updateKey.
UpdateKey toimii vain kerran. Ja vaikka joku sniffaisi itselleen uuden appId:n, niin se ei yksinään toimi updateKey:nä.
Toki palvelinpuolella pitää olla hashatut ja hashaamattomat avaimet kannassa. Asiakkaalla taas muuttuvat avaimet esim. tiedostossa.
Ilmeisesti pystyt itse vaikuttamaan tuohon mobiilisovellukseen? Jos näin niin näkisin että challenge-response -tekniikalla sopii kuin nakutettu tilanteeseesi.
Palvelimella luot challengeja ja lähetät niitä tarpeen mukaan. Käytännössä jos tarvitset jotain seurantaa tjms. muuta mikä vaikuttaa voiko tällä tunnuksella ja salasanalla suorittaa toiminnon tässä kohtaa, niin laskelmoit sen palvelimen päässä ja et esim. lähetä challengea ollenkaan (käyttäjä ei siis pysty kirjautumaan). Kuitenkin siis yhden "challengen" avulla voi kirjautua vain sen yhden kerran (ja näitä challengeja ei tarvitse kovakoodata etukäteen tjms. vaan luot ne aina satunnaisesti).
Varsinaisen challenge-response toteutuksen voi tehdä monella tapaa, mutta suosittelen jotain tällaista (lähinnä siitä syystä että sinun ei tarvitse tallentaa salasanoja palvelimelle selväkielisenä tai muuten hyökkääjälle käyttökelpoisina):
http://openwall.info/wiki/people/solar/
Joo pitääpä ottaa selvää tosta challenge-response hommasta, tuntuis kyllä olevan sopivahko. Ja kattoo myös tuo HTTP Digesti, jos sitä voisi käyttää.
Ööh...
Eikös se ole ihan samaa selväkielistä webbisivua, mitä se sieltä pukkaa? Autentikaatio on vain kohinaksi generoitu. Mainitsit sanan suht koht hyvin suojattu. Laita softasi siis https:lle. Siis jos raporteissa on jotain merkittävää.
Kylhän https:n vaihtoehdon mainitsin, sen toimivuudesta PhoneGapillä kaikilla mobiililaitealustoilla mitä PhoneGap tukee on kyllä epävarmaa. Tarkoitushan tiedot on cryptata vaikka BlowFishillä kuhan nuo käyttäjän tunnistatumiset saa tehtyä. Raporttien tieto ei sinänsä sisällä mitään kauhean arkaa tietoa, joten tärkeämpää kumminkin on, että kirjautuminen on hyvin suojattu. Ja se että sisäänkirjautuminen ei onnistu, jos joku ulkopuolinen näkee kirjautumiseen käytetyt tarkisteet.
Synomi kirjoitti:
Kylhän https:n vaihtoehdon mainitsin, sen toimivuudesta PhoneGapillä kaikilla mobiililaitealustoilla mitä PhoneGap tukee on kyllä epävarmaa.
Mielestäni ei ole. Eiköhän kaikki mobiilialustat mitkä tukee HTML5:ttä ja siten PhoneGapia tue myös HTTPS:ää. Sanotaanko näin, että tuo PhoneGap rajoittaa huomattavasti enemmän laitevalikoimaa kuin HTTPS.
Grez kirjoitti:
Synomi kirjoitti:
Kylhän https:n vaihtoehdon mainitsin, sen toimivuudesta PhoneGapillä kaikilla mobiililaitealustoilla mitä PhoneGap tukee on kyllä epävarmaa.
Mielestäni ei ole. Eiköhän kaikki mobiilialustat mitkä tukee HTML5:ttä ja siten PhoneGapia tue myös HTTPS:ää. Sanotaanko näin, että tuo PhoneGap rajoittaa huomattavasti enemmän laitevalikoimaa kuin HTTPS.
Niin kylhän PhoneGap rajoittaa, mutta myös antaa mahdollisuuden käyttää GPS:ää ja kameraa, joita tässä projektissa tarvitaan. Mitä tuota https:ää googlailin niin tuli ongelmia vastaan, joissa oli jotain sertifikaatti ongelmia. Kylhän sitä tuon muuttaa https:lle, jos se toimii itse laitteessa sillä hyvin. Tässä ei viellä ole ohjelmaa päässyt testaan itse iPad2:ssa, mutta kohta pitäisi päässä, kun saa Applen hyväksymään tunnukset.
Aihe on jo aika vanha, joten et voi enää vastata siihen.