Hur fungerar ett säkert login på en mobil applikation?

Permalänk

Hur fungerar ett säkert login på en mobil applikation?

Vi säger jag t.ex. tänker logga in på min facebookapp på min mobil. Vart sparas då mitt lösenord? Jag tänker skapa ett login på en mobilapp med Java för Iphone & Android (GluonHQ). Men hur ska jag spara lösenord för nästa gång öppnar appen så ska jag loggas in automatiskt.

Har ni några förslag?

Permalänk
Medlem
Skrivet av heretic16:

Vi säger jag tänker logga in på min facebookapp på min mobil. Vart sparas då mitt lösenord? Jag tänker skapa ett login på en mobilapp med Java för Iphone & Android (GluonHQ). Men hur ska jag spara lösenord för nästa gång öppnar appen så ska jag loggas in automatiskt.
Har ni några förslag?

Du får aldrig tillgång till användarens lösenord utan du får en "access token" som kan sparas.
https://developers.facebook.com/docs/facebook-login/
https://developers.facebook.com/docs/facebook-login/access-to...

Permalänk

Det förväntar jag mig. Det är vad jag tänker göra är själv en mobilapp och jag måste tänka på säkerheten. Hur gör Facebook och hur kan jag göra likadant?

Skulle man kunna ha krypterat lösenord i någon fil? Så fort man startar appen så läser den filen och in med krypterade lösenordet. Sedan så loggar den in?

Notera att det är inget facebookapp jag tänker göra. Jag tänker bara göra eget litet bokningssystem.

Permalänk
Medlem
Skrivet av heretic16:

Det förväntar jag mig. Det är vad jag tänker göra är själv en mobilapp och jag måste tänka på säkerheten. Hur gör Facebook och hur kan jag göra likadant?

Skulle man kunna ha krypterat lösenord i någon fil? Så fort man startar appen så läser den filen och in med krypterade lösenordet. Sedan så loggar den in?

Notera att det är inget facebookapp jag tänker göra. Jag tänker bara göra eget litet bokningssystem.

Länken du fick säger ju allt. Använd facebooks sdk.

Permalänk
Medlem
Skrivet av heretic16:

Det förväntar jag mig. Det är vad jag tänker göra är själv en mobilapp och jag måste tänka på säkerheten. Hur gör Facebook och hur kan jag göra likadant?

Skulle man kunna ha krypterat lösenord i någon fil? Så fort man startar appen så läser den filen och in med krypterade lösenordet. Sedan så loggar den in?

Notera att det är inget facebookapp jag tänker göra. Jag tänker bara göra eget litet bokningssystem.

Disclaimer: Jag utvecklar inte webbapplikationer (endast desktop-applikationer) så det finns andra som vet mer än mig och har mer erfarenhet inom detta område.

Men vad jag har förstått så ska du aldrig spara ner lösenordet, inte ens i en krypterad fil. Första gången användaren loggar in med appen mot en server så skriver dom in ett användarnamn och lösenord. Det lagrar du inte utan istället så loggar du in med dessa uppgifter direkt. Som svar från servern får du en access-token. Det är denna token du vill spara i appen.

Nästa gång de startar appen behöver de inte logga in för de har då redan denna access-token.

Sedan är det upp till dig att bestämma hur länge denna access-token ska vara giltig, du vill kanske att den bara är giltig i 1 månad och du tvingar användaren att logga in en gång i månaden.

Om det inte är du som har gjort servern (dvs du har inga rättigheter att ändra servern så att den genererar en access-token vid login) så är det såklart svårare. Då vet jag inte om det går utan lösa att spara ner lösenordet och då kommer det inte vara säkert och någon som hackar telefonen kommer kunna komma åt lösenordet även om det är krypterat.

Permalänk
Skrivet av Skyflyer:

Disclaimer: Jag utvecklar inte webbapplikationer (endast desktop-applikationer) så det finns andra som vet mer än mig och har mer erfarenhet inom detta område.

Men vad jag har förstått så ska du aldrig spara ner lösenordet, inte ens i en krypterad fil. Första gången användaren loggar in med appen mot en server så skriver dom in ett användarnamn och lösenord. Det lagrar du inte utan istället så loggar du in med dessa uppgifter direkt. Som svar från servern får du en access-token. Det är denna token du vill spara i appen.

Nästa gång de startar appen behöver de inte logga in för de har då redan denna access-token.

Sedan är det upp till dig att bestämma hur länge denna access-token ska vara giltig, du vill kanske att den bara är giltig i 1 månad och du tvingar användaren att logga in en gång i månaden.

Om det inte är du som har gjort servern (dvs du har inga rättigheter att ändra servern så att den genererar en access-token vid login) så är det såklart svårare. Då vet jag inte om det går utan lösa att spara ner lösenordet och då kommer det inte vara säkert och någon som hackar telefonen kommer kunna komma åt lösenordet även om det är krypterat.

Du menar en sorts kaka man sparar? I form av text?

Permalänk
Medlem
Skrivet av heretic16:

Det förväntar jag mig. Det är vad jag tänker göra är själv en mobilapp och jag måste tänka på säkerheten. Hur gör Facebook och hur kan jag göra likadant?

Skulle man kunna ha krypterat lösenord i någon fil? Så fort man startar appen så läser den filen och in med krypterade lösenordet. Sedan så loggar den in?

Notera att det är inget facebookapp jag tänker göra. Jag tänker bara göra eget litet bokningssystem.

Om man känner sig minsta lilla osäker på hur man ska spara lösenord i en applikation som man tänker produktionssätta, så bör man inte hantera lösenord.

Använd istället Facebook, Google, Auth0 eller liknande lösningar för att hantera användare och inloggning.

Ska man prompt hantera lösenord själv så bör man läsa på om hasning och saltning etc.

Visa signatur

| EVGA Z170 FTW | i7 6700k | ASUS RTX 3070 | 16GB DDR4 3200MHz | Cooler Master V850 | Samsung 840 Evo 250GB + 2x WD Black 500GB + Seagate 2TB SSHD + Samsung 970 Evo M.2 500GB |

Permalänk
Skrivet av BrutalSwede:

Om man känner sig minsta lilla osäker på hur man ska spara lösenord i en applikation som man tänker produktionssätta, så bör man inte hantera lösenord.

Använd istället Facebook, Google, Auth0 eller liknande lösningar för att hantera användare och inloggning.

Ska man prompt hantera lösenord själv så bör man läsa på om hasning och saltning etc.

Jadu. Jag tror jag får använda mig utav OAhut2. Då är jag väll säker?

Permalänk

Jag tror jag skippar OAht2. Känns jobbigt.

Tror jag sparar ned denna kaka på telefonen istället.

Vad tror ni om att kombinera dessa två förslag?

public void whenSettingCookiesOnTheHttpClient_thenCookieSentCorrectly() throws ClientProtocolException, IOException { BasicCookieStore cookieStore = new BasicCookieStore(); BasicClientCookie cookie = new BasicClientCookie("JSESSIONID", "1234"); cookie.setDomain(".github.com"); cookie.setPath("/"); cookieStore.addCookie(cookie); HttpClient client = HttpClientBuilder.create().setDefaultCookieStore(cookieStore).build(); final HttpGet request = new HttpGet("http://www.github.com"); response = client.execute(request); assertThat(response.getStatusLine().getStatusCode(), equalTo(200)); }

https://www.baeldung.com/httpclient-4-cookies

CredentialsProvider provider = new BasicCredentialsProvider(); UsernamePasswordCredentials credentials = new UsernamePasswordCredentials("user1", "user1Pass"); provider.setCredentials(AuthScope.ANY, credentials); HttpClient client = HttpClientBuilder.create() .setDefaultCredentialsProvider(provider) .build(); HttpResponse response = client.execute( new HttpGet(URL_SECURED_BY_BASIC_AUTHENTICATION)); int statusCode = response.getStatusLine() .getStatusCode(); assertThat(statusCode, equalTo(HttpStatus.SC_OK));

https://www.baeldung.com/httpclient-4-basic-authentication

Till detta

public HTTPMessage login(String username, String password) { // Basic Auth CredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials(new AuthScope(ADDRESS, PORT), new UsernamePasswordCredentials(username, password)); // Cookie BasicCookieStore cookieStore = new BasicCookieStore(); BasicClientCookie cookie = new BasicClientCookie(username, password); cookie.setDomain("." + ADDRESS + ":" + PORT); cookie.setPath("/"); cookieStore.addCookie(cookie); httpclient = HttpClientBuilder.create().setDefaultCookieStore(cookieStore).setDefaultCredentialsProvider(credsProvider).build(); return sendPost(LOGIN_URL + "?username=" + username); } /** * Send a url command and get HTTPMessage object * @param url String of our url * @return HTTPMessage */ public HTTPMessage sendPost(String url) { try { // Get the response HttpPost httppost = new HttpPost(url); CloseableHttpResponse response = httpclient.execute(httppost); // Get the HTTPMessage object String json = EntityUtils.toString(response.getEntity()); Type type = new TypeToken<List<HTTPMessage>>() {}.getType(); HTTPMessage hTTPMessage = new Gson().fromJson(json, type); hTTPMessage.setConnectionStatus(response.getStatusLine().getStatusCode()); // Return the object return hTTPMessage; } catch (IOException e) { return null; } }

Vad tror ni? Login-metoden har både kaka och auth.

Permalänk
Medlem
Skrivet av Mordekai:

Länken du fick säger ju allt. Använd facebooks sdk.

Skrivet av BrutalSwede:

Använd istället Facebook, Google, Auth0 eller liknande lösningar för att hantera användare och inloggning.

När appen fått tillbaka sin token, hur ska den användas med det API som TS antagligen vill skapa (och inte drifta hos Facebook får man förmoda) för att göra själva bokningen?

API:t behöver rimligen kunna tolka de claims, bland annat användarnamn, som finns i token:t samt validera att token:t faktiskt är utfärdat av Facebook och inte är spoofade.

Jag säger inte att råden i tråden är dåliga, bara att de inte är kompletta.

Att använda OAUTH2/OpenId Connect med en extern identitet provider kommer antagligen fungera utmärkt och vara ett bra sätt att slippa hantera lösenord. Men man ska ju vara medveten om att man i princip ger bort sin kunddatabas till en de stora teknikjättarna.

Permalänk
Skrivet av KAD:

När appen fått tillbaka sin token, hur ska den användas med det API som TS antagligen vill skapa (och inte drifta hos Facebook får man förmoda) för att göra själva bokningen?

API:t behöver rimligen kunna tolka de claims, bland annat användarnamn, som finns i token:t samt validera att token:t faktiskt är utfärdat av Facebook och inte är spoofade.

Jag säger inte att råden i tråden är dåliga, bara att de inte är kompletta.

Att använda OAUTH2/OpenId Connect med en extern identitet provider kommer antagligen fungera utmärkt och vara ett bra sätt att slippa hantera lösenord. Men man ska ju vara medveten om att man i princip ger bort sin kunddatabas till en de stora teknikjättarna.

Sådant har jag inte behov utav. Jag är mer bara intresserad att så fort jag startar appen så ska jag loggas in automatiskt. Då måste jag väll spara något på hårddisken?

Permalänk

Nu har jag kokat ihop ett annat förslag. Vad sägs som cache?

private CloseableHttpClient httpclient; /** * Login * @param address * @param port * @param username * @param password * @return */ public HTTPMessage login(String username, String password) { // Basic Auth CredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials(new AuthScope(ADDRESS, PORT), new UsernamePasswordCredentials(username, password)); httpclient = HttpClientBuilder.create().setDefaultCredentialsProvider(credsProvider).build(); // Try to login HTTPMessage hTTPMessage = sendPost(LOGIN_URL); // Check connection status if(hTTPMessage.getConnectionStatus() == HttpStatus.SC_OK) { // Save cache HttpHost targetHost = new HttpHost(ADDRESS, PORT, "http"); AuthCache authCache = new BasicAuthCache(); authCache.put(targetHost, new BasicScheme()); // Add AuthCache to the execution context HttpClientContext context = HttpClientContext.create(); context.setCredentialsProvider(credsProvider); context.setAuthCache(authCache); } return hTTPMessage; } /** * Login with cache */ public void loginWithCache() { httpclient = HttpClientBuilder.create().build(); HttpGet httpget = new HttpGet(LOGIN_URL); CloseableHttpResponse response = httpclient.execute(httpget, context); }

https://www.javaworld.com/article/2092353/httpclient-basic-au...

Vad tror ni? Hur ska jag kunna serialisera context?

Permalänk

Nä. Jag skiter i detta.
Jag väljer att spara krypterat lösenord istället.

Permalänk
Medlem

Kan vara värt en titt innan du ger upp

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Permalänk

^Teoretiker. Du kan inte lyssna på en sådan person. Dom vet inte vad dom talar om.

Jag tänker mer av behov och efterfrågan. Jag insåg att spara lösenord är både svårt och lätt. Jag väljer den lätta vägen. Jag menar, hur ofta blir krypterade lösenord knäckta? I så fall borde Webbläsare förbjudas.

Permalänk
Medlem

Använder du dig av Facebooks sign-in så frånsäger du dig all lagring av lösenord etc, vilket kan vara rätt skönt. Användaren loggar in via en Facebooks api, du får skapa ett Facebook developer account för detta, se här. På så vis får du tillbaka om användaren är inloggad och med det även email / namn från Facebook. Detta kan du då använda för att skapa upp en användare i ditt system, men utan lösenord då detta hålls via Facebook.

Om du väljer att ändå skapa det själv så skulle jag rekommendera JWT-tokens, generellt vill du ju ha samma sign-in API för din desktop, mobil och webbsida, för att slippa ha denna logik på flera ställen. Ett scenario är att en kund använder mobilappen och hemsidan, då ska man ju inte behöva skapa två olika konton för detta.

Jag är ingen java programmerare, men det bör finnas något färdigt auth-system likt ASP Core Identity i .NET. Detta kan nog du som Javautvecklare bättre än mig.

Lösenord ska hashas och då ska det användas en one way hash av lösenordet. Du ska aldrig spara ett lösenord direkt i databasen.
När användaren sedan loggar in så får du hasha lösenordet som angetts och jämföra med det hashade värdet i databasen för att validera användaren.

Av det jag snabbt googlar så använder flera inom Java något som heter SharedPreferences där du sparar värdet i ett key-value pair. SharedPreferences.
Detta kan då användas för att validera en användare direkt då appen körs igång.

Skrivet av heretic16:

^Teoretiker. Du kan inte lyssna på en sådan person. Dom vet inte vad dom talar om.

Jag tänker mer av behov och efterfrågan. Jag insåg att spara lösenord är både svårt och lätt. Jag väljer den lätta vägen. Jag menar, hur ofta blir krypterade lösenord knäckta? I så fall borde Webbläsare förbjudas.

Tycker alla Computerphile videos är väldigt intressanta. Jag tycker att de verkligen vet vad de talar om.
Det är viktigt att ha koll på bl.a. SQL-injection, cookie-stealing och session hijacking så du inte lämnar dina kunders information sårbart.

Edit:
Du har inte kikat på Firebase? Ger dig väldigt mycket av det du efterfrågar

Permalänk
Medlem
Skrivet av heretic16:

^Teoretiker. Du kan inte lyssna på en sådan person. Dom vet inte vad dom talar om.

Jag tänker mer av behov och efterfrågan. Jag insåg att spara lösenord är både svårt och lätt. Jag väljer den lätta vägen. Jag menar, hur ofta blir krypterade lösenord knäckta? I så fall borde Webbläsare förbjudas.

Det är inte teori, det är även i praktik han pratar och lösenordsskydd är ett matematiskt, statistiskt och teoretiskt fält då du måste räkna på risken att något sker, hur svårt det är etc
Lösenord blir knäckta hela tiden och i många fall är de som implementerat systemen väldigt duktiga men även de gör missar, det räcker med en väg in så är det en för mycket. Vad har webbläsare med lösen att göra? krypterad kommunikation och krypterade lösen är inte samma sak och följer inte samma principer när det kommer till att skyddas.

Visa signatur

"One is always considered mad, when one discovers something that others cannot grasp."
- Ed Wood

Permalänk

Jag skulle inte rekommendera något som basic authentication. Och framför allt, koda inte din egen säkerhetslösning på API (backend) sidan.

Authentication/Identifiering:
En process för att identifiera sig. Desto mer du litar på källan som ger dig identifikationen desto bättre.

Exempel:

(SVAG) En person ringer upp och säger att han heter Kalle Anka med personnummer xxxxxxxx-xxxx. (Basic Authentication)

IT - Skickar användarnamn och lösenord som base64 kodat info i HTTP headern.

(OK) En person ringer upp och anger en lång kod som han fått via login (kanske med verifikation via till en etablerat och förtroende ingivande part (facebook/microsoft/a. Koden verifieras (på mottagarsidan mot en nyckel/certifikat som de redan har. Verifieringen sker mot den krypterad koden som innehåller vem Kalle vill verifiera sig mot (i vissa fall), hur länge koden är giltig (t.ex. 2h) och vem som skapat koden.

IT - Kalle försöker ansluter mot API X, men får tillbaka 401 Unauthorized, och får även tillbaka en redirect adress som pekar på en inloggning mot en officiel Facebook, Azure AD/Microsoft, AWS, Auth0, Ping etc inloggning. Inloggningen ger tillbaka en JWT (token) som Kalle skickar med i alla följande HTTP requests mot API't. När giltighetstiden går ut, måste Kalle identifiera sig igen. (Vissa varienter på detta finns)
API'et verifierar token mot en nyckel/certifikat (från Facebook, Microsoft/Azure AD etc och unikt för din API) eller ställer en verifiering request mot Facebook, microsoft etc för validering (skickar Kalles token + en hemlig nyckel).
Alternativt. Använd ett certifikat på API sidan som är 'trusted' och har motsvarande certifikat installerat per användare. Bra inom organisationer.

(säkrast?) Om du behöver verifiera faktiskt fysisk person, använd t.ex. BankId. Om jag inte har fel så fungerar det i grunden som beskrevs ovan förutom att banken/staten är verifierare istället för Facebook etc.

Vilken utgivare av token du vill ha är beroende på vilka användarna är.
Är det inom en organisation som har sin egen katalogtjänst (te.x Active Directory) och/eller personer som registrerat sig direkt mot din tjänst (API), är det troligtvis Azure AD, Ping, Auth0, IdentityServer(.net)/IdentityServer(java) etc (de två sistnämda kan du hosta själv) som gäller. Noter att vid registrering så måste du koda den delen på API och klient.
Om användarna är okända, från det öppna internet, då kanske Facebook, Microsoft, Google funkar.

Och naturligtvis, utan HTTPS fungerar inga av de ovanstående metoderna.

Authorization/Behörighet:
Behörighetskoll måste alltid ske på API sidan. Målet är att returnera en 403 Forbidden för allt användaren inte ska kunna göra.
Hur behörighetskontrollen ser ut är olika, men i stora drag kan man:
- Via token få ut ett användar id. Slå upp i katalogtjänsten vilka behörigheter/roller denna användare har. (te.x. via ett active directory eller motsvarande i Auth0, IdentityServer etc).
- Den som skapar token inkluderar behörighet/roller i själva token.

Permalänk
99:e percentilen
Skrivet av heretic16:

^Teoretiker. Du kan inte lyssna på en sådan person. Dom vet inte vad dom talar om.

Jag tänker mer av behov och efterfrågan. Jag insåg att spara lösenord är både svårt och lätt. Jag väljer den lätta vägen. Jag menar, hur ofta blir krypterade lösenord knäckta? I så fall borde Webbläsare förbjudas.

Skärp dig nu. Tom Scott är välkänt duktig på säkerhet, medan du knappt uppvisar grundläggande förståelse. (Inte minst citatet ovan visar tydligt på det.) Be gärna om hjälp på forumet, men ta då också till dig av vad vi skriver och svara inte bara med tvärsäkra påståenden som du inte kan belägga. Normalt sett låter jag inlägg likt ovan passera, men när det gäller säkerhet kan jag inte bara sitta och se på när du postar så fullständigt ogrundade uttalanden.

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem
Skrivet av Alling:

Skärp dig nu. Tom Scott är välkänt duktig på säkerhet, medan du knappt uppvisar grundläggande förståelse. (Inte minst citatet ovan visar tydligt på det.) Be gärna om hjälp på forumet, men ta då också till dig av vad vi skriver och svara inte bara med tvärsäkra påståenden som du inte kan belägga. Normalt sett låter jag inlägg likt ovan passera, men när det gäller säkerhet kan jag inte bara sitta och se på när du postar så fullständigt ogrundade uttalanden.

Jag gick en grundläggande kurs för programmering inom säkerhet och det fick mig att inse att det nog är bäst att lämna över det till bibliotek och tjänster vars utvecklare vet vad de faktiskt håller på med. Det finns såklart en risk att använda autentisering via tredjepart som tex Facebook men i många fall är det ju ändå bättre än att hitta på något själv. Kan även vara rätt kul att dra ner Kali och experimentera och kanske följa med i någon kurs/blogg och testa hur lätt det är att hitta vissa lösenord.

Annars är ju grundprincipen att man haschar och saltar lösenord, sparar det och jämför värdet.

Ytterligare en bra film från ComputerPhile: https://youtu.be/7U-RbOKanYs

Skickades från m.sweclockers.com

Permalänk

Okej.

Jag her Oauth2 en chans med Spring Boot.
https://www.baeldung.com/spring-security-5-oauth2-login

Någon som vet hur man hanterar HTTP kommando för att logga in via OAuth2 ?

Skickades från m.sweclockers.com

Permalänk

Jag ger upp.

Såg att Google erbjuder OAuth2, men den kostar pengar. Så då kan jag lika gärna ha krypterat lösenord i en databas.

Permalänk
Medlem

Finns ett sätt du kan göra utan auth via tjänster eller hantera lösenord. Magic links.
Användaren anger sin epostadress och får ett mail med en länk. När anv klickar på länken så valideras sessionen och användaren är authentiserad.
Pros and cons som alltid, men det är ett sätt.
Annars finns som nämt firebase auth som kan rekomenderas

Skickades från m.sweclockers.com

Visa signatur

Oldschool [å:ldsku:l] adj. Användandet av datorprodukter som är äldre än 3 månader.

Permalänk
Skrivet av kundun:

Finns ett sätt du kan göra utan auth via tjänster eller hantera lösenord. Magic links.
Användaren anger sin epostadress och får ett mail med en länk. När anv klickar på länken så valideras sessionen och användaren är authentiserad.
Pros and cons som alltid, men det är ett sätt.
Annars finns som nämt firebase auth som kan rekomenderas

Skickades från m.sweclockers.com

Firebase! Aldrig hört talas som detta. Men det måste nog fungera riktigt bra?
Är det gratis?

Permalänk

Vänta nu lite!

Så jag har spenderat timmar och massa skitsaker på att lära mig Spring och inte lyckats göra säker inloggning.

Sedan finns det något som heter Firebase som erbjuder databas och inlogg....helt gratis??? Jag behöver inte ens ha en server for detta???

Permalänk
Medlem

Obehaglig läsning

Skickades från m.sweclockers.com

Permalänk
Medlem

Ännu ett sätt att skippa inlogg o lösenord är att helt enkelt lagra datan på användarens enhet mha localstorage eller indexedDb. Allt beror ju på vad du ska bygga och hur känslig datan är.

Skickades från m.sweclockers.com

Visa signatur

Oldschool [å:ldsku:l] adj. Användandet av datorprodukter som är äldre än 3 månader.

Permalänk
Skrivet av kundun:

Ännu ett sätt att skippa inlogg o lösenord är att helt enkelt lagra datan på användarens enhet mha localstorage eller indexedDb. Allt beror ju på vad du ska bygga och hur känslig datan är.

Skickades från m.sweclockers.com

I detta fall handlar det om att boka tider.

Permalänk

@Ernesto:

Utveckla vidare, tack.

Permalänk
Medlem
Skrivet av heretic16:

Firebase! Aldrig hört talas som detta. Men det måste nog fungera riktigt bra?
Är det gratis?

https://firebase.google.com/pricing