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

Varför så otrevlig ton? Jag lindade kanske inte in mitt budskap men avsikten var inte att säga åt dig att "RTFM".

Det är just det jag menar, du ska ju inte lagra lösenordet någonstans, eftersom det bara ska finnas hos den som skrev meddelandet och den som ska läsa det.

Bcrypt är ett säkrare (tekniskt sett mer kostsamt) sätt för att hasha lösenord, det stämmer, men det är det ohashade lösenordet som används för kryptera och avkryptera datan, så varför hasha lösenordet alls?

Som sagt, om det hashade lösenordet aldrig används så är det väl meningslöst att hasha det till att börja med. Missar jag något här?

Min poäng här var att backendens jobb består i två saker:
1. Att lagra krypterad data och
2. Ge ut en referensnyckel till den krypterade datan, så att en läsare kan nå den genom en "snygg" URL.

Vad som är "snyggt" är ju subjektivt så klart, men jag menade någon sorts hash som unikt identifierar den lagrade datan.

Ingen fara, jag kunde ha använt en trevligare ton.

Jag tänkte mig snarare en hash på den krypterade datan—men jag ser att du använder ett UUID vilket fungerar lika bra! Lösenordet, hashat eller ej, ska aldrig behöva skickas separat till servern. Om jag har läst den senaste versionen av din kod rätt så skapar du länken för läsning på klientsidan och skickar faktiskt aldrig lösenordet till servern, så själva "skickandes av lösenord" är ju löst.

Det kvarstår ett par problem:

1. Den krypterade datan är inte signerad, så det går inte att verifiera att innehållet inte har ändrats. Detta innebär att servern kan modifiera innehållet i filen utan att användaren märker detta.
2. Det går inte att verifiera att läsaren har angett rätt lösenord.

Att lägga till det BCryptade lösenordet i länken löser tekniskt sett 2. men löser inte 1.

Vad du önskar göra när en läsande användare anger ett lösenord är att använda det för att först verifiera att den krypterade datan är oförändrad (dvs att servern inte har gjort något fuffens med den), samt att avkryptera den.

Bägge problem kan lösas med en kombination av AES (förslagsvis) och MAC. Idén är att skapa en signatur av den krypterade datan som bara går att verifiera om både signaturen och den krypterade datan ej har ändrats av något eller någon. Signaturen behöver delges till läsaren på något sätt, men det går att bädda in den i den krypterade datan.

För att undvika att uppfinna hjulet på nytt och/eller skapa helt nya säkerhetsbrister kan du använda dig av en färdig variant som gör precis det här och kallas GCM; teknikerna och processen beskrivs bättre här: https://security.stackexchange.com/a/63134.

Förhoppningsvis går det att hitta ett trevligt bibliotek som löser GCM åt dig, annars får du hålla tungan rätt i mun och följa en guide i den här stilen: https://medium.com/@thomas_40553/how-to-secure-encrypt-and-de...

Notera att jag är en intresserad lekman och ingen expert. Jag kan inte avgöra om lösningarna som jag länkat till ovan faktiskt implementerar den bästa lösningen på problemet, men det är intressant läsning om inte annat!

Jag tror missförståndet ligger här i, när vi har skrivit Javascript så har vi menat client-side, inget NodeJS eller liknande.

I frågan om hur websidan ska veta att det är rätt lösenord så gav jag dig alternativet WebCryptoAPI som vad jag förstått det har funktionen inbyggd.
Ett annat alternativ som jag kom på efter jag skrev mitt svar är att du på text-strängen bara lägger till "ENC!" eller liknande INNAN du krypterar den. När det sen avkrypteras så kollar du bara om de första fyra tecknen är "ENC!" Att någon matar in ett lösenord som vid avkryptering ger samma första tecken men inte resten är i praktiken omöjligt.
Du kan också bygga vidare på förslaget från @Teknocide om att hasha in-datan och kontrollera om det blir samma hash efter mottagaren har angett ett lösenord. Du behöver faktiskt inte ens spara hashen på servern, bara lägg den som en GET-parameter.
Båda lösningarna undviker helt att lösenordet sparas på servern i någon form.