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

Tjo igen! Som andra redan starkt rekommenderat så kan du betrakta lösenord som något som alltid bearbetas innan det egentligen skulle kunna göra någon skada, t.ex., innehålla skadlig körbar kod. Du förvandlar ju lösenordet direkt efter inmatning så saneringsfunktionen av att ta bort mellanslag före och efter det tappar sitt syfte jämfört med inmatningsfält där något kommer att lagras precis som det matats in (t.ex. e-postadress, för- & efternamn., med mera).

Jag skulle också starkt rekommendera att inmatningsfält för lösenord som bör förvandlas omedelbart (hashas eller krypteras på annat vis) behöver ingen inmatningssanering i form av radera mellanslag före och efter så tillvida inte du redan har bestämt dig för vilka slags tecken som får matas, dvs., datavalidering. Detta bör ju dock synas med någon liten paragraf under inmatningsfältet, t.ex. "Endast följande tecken får användas för lösenordet: a-öA-Ö0-9!"#¤%&/()".

Exempel på där du kanske vill "standardisera" hur något ska se ut efter inmatning är exempelvis telefonnummer. Jag gjorde i ett projekt så att telefonnummer kan matas in via +46-076 123456 men sedan lagras det alltid med enbart siffrorna (46076123456) så att telefonnumren ser identiska ut. Huruvida detta bör ske redan under inmatningen, dvs., att du inte kan ange +, mellanslag och/eller - är en annan oändlig hårklyveridiskussion, imho.

För lösenord rekommenderar jag starkt: antingen meddela redan i klienten vilka tecken som tillåts och validera efter inmatning (anta någon fular sig och skickar POST via Thunderclient) eller så tillåter du alla tecken.

Mvh,
WKF.

Varför det fetstilta? Det blir krypterat, det finns alltså ingen risk att något ö.h.t. injiceras för att skada andra.
Väljer du att dela JS-kod så får du väl dela JS-kod? Se till att bara skriva ut det som text dock (t.ex. jQuery .text()), och inte som att lägga ut det rakt upp och ner (för då blir det antagligen HTML, om HTML är i meddelandet).

Lösenordet är dessutom något som endast används i klienten, har svårt att se hur du skulle kunna få in någon sårbarhet genom XSS eller liknande där.

Allt du gör för att förändra lösenordet kan potentiellt försvaga det. Tänk på vad det är för tjänst du utvecklar.. du vill kunna dela innehåll (meddelandet) på ett säkert sätt. Inte att du ska skapa ett konto där lösenordet kommer användas flera gånger.
Nu handlar det om engångslösenord. Får mottagaren fel lösenord (kan inte avkryptera meddelandet) så får de väl dela om det och se till så det blir rätt från första början

Förklara gärna detta? Självklart blir lösenordet svagare om du minskar antalet tecken? Och varför skulle det nu inte vara rekommenderat?
https://security.stackexchange.com/questions/32691/why-not-al...
https://www.infosecmatter.com/spaces-in-passwords-good-or-a-b...
https://stackoverflow.com/questions/632167/should-users-be-al...
https://pages.nist.gov/800-63-4/sp800-63b/passwords/#complexi...
osv..

Det är möjligt att sanitera meddelandet innan du skrivet ut det som text. Alltså att omvandla <, >, o.s.v. till html-entiteter - du ser ingen skillnad på skärmen, men i bakgrunden tolkas det som text istället för ett DOM-element.

function escapeHtml(text) {
    return text.replace(/&/g, "&")
      .replace(/</g, "&lt;")
      .replace(/>/g, "&gt;")
      .replace(/"/g, "&quot;")
      .replace(/'/g, "'");
}

@Airikr Om det är på PHP-backend krypterad text först dekrypteras och sedan skickas tillbaka till frontend så går det att använda htmlspecialchars() vilket är den inbyggda PHP-funktionen för att omvandla vissa webbtecken att tolkas som ren text istället för körbar webbkod.

Den där funktionen rekommenderas starkt för utskrift av all användarerhållen data från exempelvis formulär, lagrat i databaser, med mera. Det är den som gör att jag kan skriva <script>alert(document.cookie);</script> här utan att hela omgivningen får se alla mina Sweclockers-kakor!

Mvh,
WKF.

Ett exempel;

Lösenord: "123"
Meddelande: "hej 123"

Kryptera meddelandet med lösenordet, det ger dig; "abcxyz"
Lägg på lösenordet på detta meddelande, vilket då ger dig följande; "123abcxyz"
Kryptera det sedan igen med lösenordet, vilket ger dig; "asdfghijdj"

När du sedan gör det omvända så avkrypterar du med lösenordet "123" och får "123abcxyz". Du kan då jämföra om meddelandet börjar med lösenordet eller ej - vilket det i det här fallet gör. Alltså har du angett rätt lösenord.
Du kan därmed plocka bort lösenordet från meddelandet och sedan avkrytera det igen för att slutligen få "hej 123".

Notera att detta bara är ett exempel för en lösning på hur du kan verifiera att rätt nyckel används vid avkrypteringen. Jag är bara en "vanlig" utvecklare och är ingen säkerhetsexpert/expert inom kryptografi

Okej.. förtydligar lite mer då

Lösenord: 123
Meddelande: Hej

Hashat lösenord: absyhbdhuyashduasdjsaujdiasjidojasoid

Steg 1:
Kryptera meddelandet.
(resultat: 9823902j3290ijmdasjd)

Steg 2:
Hasha lösenordet och lägg på den hashade lösenordssträngen på det krypterade meddelandet;
"absyhbdhuyashduasdjsaujdiasjidojasoid#!ENC!#9823902j3290ijmdasjd"
(#!ENC!# används mellan hashet och krypterade meddelandet som exempel på hur du kan förhindra att det krypterade meddelandet också tolkas som en del av lösenordet)

Steg 3:
Kryptera meddelandet (som nu också innehåller ditt hashade lösenord) igen med lösenordet;
(resultat: jiausjdu89sahd897j821j9a98sdj89as)

Steg 4:
Ladda upp det krypterade meddelandet till din backend/databas.

När du sedan ska göra det omvända, alltså avkryptera meddelandet, så blir det följande;

Steg 1:
Hasha lösenordet som anges.
(resultat: absyhbdhuyashduasdjsaujdiasjidojasoid)

Steg 2:
Avkryptera meddelandet (jiausjdu89sahd897j821j9a98sdj89as) med lösenordet.
(resultat: absyhbdhuyashduasdjsaujdiasjidojasoid#!ENC!#9823902j3290ijmdasjd)

Steg 3:
Kontrollera om början av meddelandet (fram till din avskiljare, i det här fallet "#!ENC!#") är samma som det hash du genererade för lösenordet.
(absyhbdhuyashduasdjsaujdiasjidojasoid)

Steg 4:
Om hashet är identiskt så har du rätt lösenord.
Avkryptera det inre meddelandet (9823902j3290ijmdasjd) med lösenordet (123).
(resultat: "Hej")

Klart

Du måste ha missförstått. Det som behöver göras är bara en förändring hur du krypterar/avkrypterar meddelandet.
Sql borde rimligtvis förbli oförändrad i din backend

Om hashet du skapar på klienten är samma som finns i meddelandet efter du avkrypterat första gången, så är det ju rätt lösenord. Har du avkrypterat med fel lösenord så kommer det vara helt scrambled och du kan inte tyda innehållet

Tänk ett paket.. du har din produkt i sin originalkartong, därefter lägger du originalkartongen i ett yttre emballage tillsammans med en lista över innehållet.
Du öppnar yttre emballaget och kontrollerar listan (som i då är ditt lösenord) - om det inte stämmer med vad du köpt så kommer du returnera paketet, för det är ju inte rätt.
Annars tar du glatt ur originalkartongen och öppnar för att få din produkt.

Annars tycker jag du ska kolla upp HMAC, som är "rätt" sätt att göra det hela på. Skickar lite kodexempel nedan på en simpel implementering endast med hjälp av CryptoJS

Input message: "hejsan hoppsan"
Password: "swec"
Output (encrypted): "670289e2138d14da5b0498f41adf8a3d$U2FsdGVkX1+659hX556z7DcbLhqB4J0qhPbZZShynmY=$961cf75dfaecf53b7933c8ecb04bce293204a2b55f480f9d9f6d6cb25f1ae116"

(fetstilta är meddelandet)

function encryptMessage() {
    const message = document.getElementById('message').value;
    const password = document.getElementById('password').value;
    if (!message || !password) {
        alert('Please enter both the message and password.');
        return;
    }
    try {
        // Generate a random salt
        const salt = CryptoJS.lib.WordArray.random(128 / 8);
        console.log("Salt:", salt.toString());
        // Derive a key using PBKDF2
        const key = CryptoJS.PBKDF2(password, salt, {
            keySize: 256 / 32,
            iterations: 1000
        }).toString();
        console.log("Derived Key:", key);
        // Encrypt the message using the derived key
        const encrypted = CryptoJS.AES.encrypt(message, key).toString();
        console.log("Encrypted Message:", encrypted);
        // Generate an HMAC for integrity verification
        const hmac = CryptoJS.HmacSHA256(encrypted, key).toString();
        console.log("HMAC:", hmac);
        // Combine salt, encrypted message, and HMAC
        const combinedMessage = salt.toString() + "$" + encrypted + "$" + hmac;
        document.getElementById('result').value = combinedMessage;
    } catch (error) {
        alert('Encryption failed: ' + error.message);
        console.error("Encryption Error:", error);
    }
}

function decryptMessage() {
    const combinedMessage = document.getElementById('message').value;
    const password = document.getElementById('password').value;
    if (!combinedMessage || !password) {
        alert('Please enter both the encrypted message and password.');
        return;
    }
    try {
        const parts = combinedMessage.split('$');
        if (parts.length !== 3) {
            throw new Error('Invalid format: Expected salt, encrypted message, and HMAC.');
        }
        const salt = CryptoJS.enc.Hex.parse(parts[0]);
        const encryptedText = parts[1];
        const hmacStored = parts[2];
        console.log("Extracted Salt:", salt.toString());
        console.log("Encrypted Text:", encryptedText);
        console.log("Stored HMAC:", hmacStored);
        // Derive the decryption key from the password and salt
        const key = CryptoJS.PBKDF2(password, salt, {
            keySize: 256 / 32,
            iterations: 1000
        }).toString();
        console.log("Derived Key:", key);
        // Verify the HMAC to check integrity
        const hmacCalculated = CryptoJS.HmacSHA256(encryptedText, key).toString();
        if (hmacCalculated !== hmacStored) {
            throw new Error('Invalid password or message integrity compromised.');
        }
        // Decrypt the message
        const decrypted = CryptoJS.AES.decrypt(encryptedText, key).toString(CryptoJS.enc.Utf8);
        if (!decrypted) {
            throw new Error('Decryption failed: Incorrect password or corrupted data.');
        }
        document.getElementById('result').value = decrypted;
    } catch (error) {
        alert('Decryption failed: ' + error.message);
        console.error("Decryption Error:", error);
    }
}

Eftersom det är end-to-end-encryption med ett av användaren givet lösenord som du försöker lösa så ska lösenordet ALDRIG skickas till servern, vare sig i klartext eller i hashad form. Lösenordsverifiering och avkryptering måste sådeles ske i frontend.

Datan som har krypterats av frontend skickas till backend som sparar undan den och genererar en unik adress för det objekt som tagits emot. Backendens roll blir med andra ord att lagra data och skapa snygga URLer för att nå (ladda ner) datan i krypterad form.

Då avkryptering behöver ske i frontend kommer alla som besöker en backend-genererad länk få ladda ner det krypterade objektet.

Bcrypt är ett villospår: resultatet av att kryptera en och samma nyckelfras, exempelvis "korv", vid två olika tillfällen kommer ge olika resultat, testa själv på exempelvis https://bcrypt-generator.com/

Vad du vill göra istället är att använda någon sorts symmetriskt krypteringssystem, till exempel Twofish eller AES för att kryptera datan, innan den skickas till backend.

Det låter som att du fortfarande är inne på att skicka lösenordet till servern och spara det i någon form, hashat/krypterat, jag tror det är källan till kommentaren från @Teknocide

Du har fått förslag från @Pamudas på hur du kan skriva en egen funktion för att verifiera att det är rätt lösenord innan decryption av datan görs. Det innebär visserligen att lösenordet finns lagrat på servern, men i det här fallet både hashat och sen krypterat vilket jag tycker är en rätt snygg lösning.

Ett annat alternativ är att titta på ett annat crypto-bibliotek som kan göra den kollen åt dig, mitt tips är Web Cryptography API vilket alla stora webläsare har implementerat.

Här finns exempelkod från en chatbot ihop med mina frågor för att komma fram till det.
https://www.phind.com/search?cache=yc1pd1qauqqqqtyjh0tlo6p6

T.ex här där du pratar om SQL, vilket är server side.

Jag gjorde ett nytt test nu och kollde både webläsaren och med en separat HTTPS-proxy för att dubbelkolla.
Du skickar fortfarande lösenordet till server, och dessutom i klartext!
Jag är absolut ingen webutvecklare, men gissar att det är något galet i din form, ska man verkligen ange både en action och method i den?

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.