Enc: en krypterad meddelandetjänst baserat på engångslänkar

Jag tycker du gör helt rätt i att försöka lära dig nya saker genom att implementera dem. Det kräver en hel del mod att publicera sina projekt just på grund av risken att få helt toxisk feedback, så jag hoppas du inte blir avskräckt av en dålig upplevelse.

Som feedback på ditt projekt tycker jag att du bör lägga till en banner eller en startsida som säger att detta är ett personligt lärandeprojekt och används på egen risk. Det finns, som redan nämnts, flertalet brister i säkerheten. Sannolikheten att en slumpmässig person trillar in på din sida och försöker nyttja den är försvinnande liten, men du har ett ansvar för tjänster du publicerar och bör anta att någon kommer använda dem, även om så inte sker i praktiken. Här vet du att du inte riktigt vet vad du pysslar med (ännu, poängen är ju att du lär dig!), och det är helt okej, men se till att potentiella användare också gör det!

Lycka till med lärandet, hoppas din dag vänder!

Snyggt, men som andra har sagt, för att öka säkerheten och tilltron till tjänsten så borde du inte skicka med lösenordet till servern.
Om du på servern inte vet vad lösenordet är så vet jag som användare att du inte heller kan läsa meddelandet.

/Viktor

Vad är vitsen med hashning av lösenordet ö.h.t? (Och att då lagra lösenordet - hashat eller ej)
Kryptera meddelandet med lösenordet så är det väl klart.

Nej, det skickas inte med i klartext vad jag kan se så det är bra. Men servern behöver inte alls lösenordet. Allt du behöver skicka till servern är det krypterade meddelandet. Sen dekrypterar du meddelandet på klienten på samma sätt som du krypterade det (eller bakvänt) och använder lösenordet som besökaren angivit utan att det behöver skickas till servern eller att servern behöver veta vad det är.

/Viktor

Eller menar du att mottagaren sen skickar lösenordet (hashat) till servern, som sen jämför dessa?

Checksum är väl ett alternativ tänker jag.

Skapa en hash av meddelandet innan det krypteras, lagra sedan detta hash bredvid det krypterade meddelandet (t.ex. "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed:[ENCRYPTED_MESSAGE]"). Eftersom du vet vilken hashfunktion du använt så vet du även hur lång text den genererar. Det är alltså relativt enkelt att dela på hashet och den krypterade strängen.

När du sedan avkrypterar meddelandet så hashar du resultatet och jämför med original-hashet
Inga lösenord lagras utan endast det krypterade meddelandet.

Inga lösenord lagras utan endast det krypterade meddelandet.

Jag kan låta hård i alla mina svar här, det är inte meningen.
Men varför tar du bort mellanslag i lösenord? Det är ett tecken som vilket annat som helst och ska självklart kunna vara en del av lösenordet.
Och som skrivits flera gånger tidigare, det finns ingen anledning att skicka lösenordet till servern öht, och därmed inte heller någon anledning att hasha det.
Vad använder du hashen i URLen till när den kommer till mottagaren?

Jag tänker att det har att göra med hur du kan veta ifall meddelandet är avkrypterat eller ej.
Kan du återskapa samma hash som original-lösenordet så vet du att det är exakt samma lösenord som du låser upp med, alltså är det garanterat att du avkrypterat meddelandet korrekt.

Det går att lösa med en signatur i meddelandet (som du verifierar mot), en hash som checksum eller helt enkelt att du krypterar två gånger;
Först meddelandet, sen krypterade meddelandet + lösenordet. När du sen avkrypterar så kan du ju se om lösenordet matchar det du använde - i så fall är det rätt och du kan avkryptera det inre meddelandet.

encrypt(password+encrypt(message)) helt enkelt.

Ett bra projekt som kan vara lärorikt på flera sätt. Man kan använda kunskapen till väldigt mycket och det kan komma till nytta inom ens projekt. T.ex. om man vill kunna få flera olika system att utbyta information. Det kan även inspirera andra att själv studera ämnet.

Ett problem idag är sedan vad är säkert? På gamla Microsoft windows server så var sidor som www.microsoft.com spärrade som default, för denna webbsida kan innehålla en massa skit och var en säkerhetsrisk att besöka.

Jag försökte kolla igenom biblioteket som används men dokumentationen var inte superbra....
MEN, jag utgår från att biblioteket har den funktionen inbyggd så att du själv inte behöver tänka på det, och därmed bara returnerar "wrong password"

Varför strippa space öht, det är en del av lösenordet och du tar bort tecken från det, alltså sänker antalet möjliga kombinationer och gör det mindre säkert till ingen nytta alls.

Sen förstår jag absolut att du lär dig och vill skriva egna funktioner, men trim är en sådan funktion jag aldrig hade skrivit själv då den är såpass enkel och finns färdig i JS.

Vad använder du hashen i URLen till när den kommer till mottagaren?

Men varför göra det antagandet öht?

Om jag har angivit lösenordet " lösenord123 " (med mellanslag)
Så förväntar jag ju mig inte att man ska kunna logga in med lösenordet "lösenord123"

Kul med lokalproducerat, kämpa på @Airikr

Tjo!

Hur gör du i PHP då? Skriver du en egen regex-funktion för att radera whitespace i början+slutet av strängar istället för klassiska trim()? Vissa hjul är relativt onödiga att återskapa när de är så simpla vilket är varför det redan finns simpla funktioner för ändamålen.

Sedan skulle jag i dagsläget aldrig få för mig att försöka återskapa kryptografiska funktioner då matematiken som krävs där för att de ska bli "säkra på riktigt" saknar jag och kommer troligen aldrig inom någon rimlig tidsram hinna lära mig. Där är det kostnadseffektivast låta spetskompetenser få göra sitt åt en.

Nu påstår jag inte att du försöker återskapa kryptografiska funktioner utan bara ge exempel på vad som kan vara värt att försöka återskapa för att lära sig och vad som kan vara rätt så onödigt att försöka återskapa - för att lära sig - på grund av dess enkelhet! (eller svårighet!)

Btw, är det inte lite motsägelsefullt att du vill gärna skapa egen trim-funktion i JavaScript istället för att använda inbyggd men är helt okej med att använda jQuery vilket abstraherar bort (och därmed inlärningen av det) hur JavaScript kan användas för att tillhandahålla webbplatser med interaktivitet?🤪

Mvh,
WKF.

Så du valde svaret som höll med dig, i havet av hundratals som säger att man absolut inte ska göra det.

Finns ju t.o.m flera exempel där som förklarar case med t.ex. lösenordshanterare etc.