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

Först togs alla mellanslag från ett lösenord bort, vilket jag erkänner var fel tillvägagångssätt. Nu raderas endast mellanrum som är före och efter lösenordet. Men jag ska självklart skriva in hur allt fungerar och vad som kommer att hända

Vill bara säga detta lite snabbt. Jag kan ses som ignorant/obrydd gällande era svar, men det är oftast för att jag inte kan tänka klart och inte heller riktigt kan förstå vad ni menar. Som ett exempel var min hjärna typ avstängd i går, från kanske sena förmiddagen tills jag gick och la mig för natten. Jag tar in allt ni skriver så gott jag bara kan, och tar emot alla tips jag kan få. Men ibland kan jag verka ignorant/obrydd. Det är inte meningen.

Plus, mycket i det här projektet är helt nytt för mig. Jag måste tänka säkerhetsmässigt och sätta mig in i saker som jag aldrig har fifflat med förr.

Så sant som du säger. Kommer lägga in en validering för lösenordet som säger "ajabaja" om besökaren lägger till mellanslag före och/eller efter lösenordet, och om det är mindre än säg 8 tecken. Ett lösenord ska få vara oändligt långt om man så själv vill, och jag kommer inte begränsa några andra tecken än just mellanslagen före och efter lösenordet. Jag typ hatar tjänster som hävdar att man använder ett osäkert lösenord bara för att man har med specialtecken. Fattar inte..!

Tjo! Ja, där skrev du något, att lösenordet måste "strippas" (kommer inte på rätt ord för det) från all skadlig kod, så som injektioner av JavaScript-kod. Detta gäller även meddelandefältet. Tack Ska lägga in denna säkerhetsåtgärd innan nästa uppdatering läggs upp. Fick kritik om placeringen av loggan i går, så har gjort om lite

Som jag skrev i mitt förra inlägg, så kommer jag inte att validera lösenordet mer än att räkna antalet tecken så att ett lösenord inte bara är ett enda tecken långt. Har även lagt in en text under lösenordsfältet som berättar vad som kommer att hända när man trycker på dela-knappen, och att det måste vara minst 5 tecken långt. Att begränsa till endast godkända tecken kommer att läggas in om det visar sig att man på något sätt kan missanvända lösenordsfältet, trots sanering (rätt ord?).

Ditt telefonnummersexempel förstod jag inte riktigt Vad skulle jag kunna standardisera på Enc? Att man inte ska få ange +, - och/eller mellanslag i lösenordet? Eller... va?

En till sak: Thunderclient? Menar du Thunder Client-tillägget för VS Code och VSCodium? Jag använder endast VSCodium för och kunna komma åt servern och på så sätt kunna ändra i filer. Använder annars Lite XL då jag föredrar en mjukvara som inte använder sig av Electron och som är typ som EditPlus, min favoritmjukvara från tiden då jag använde Windows som mitt standardsystem (7+ år sen).

Lösenordet förstår jag, det förblir ju hashat även om man har angett rätt lösenord. Men när det kommer till meddelandet, så tror jag inte att någon vill att den JavaScript-kod sändaren har skickat ska köras så fort man har låst upp meddelandet Då vill man ju läsa koden. Så det kommer jag att fixa till (om det ens sker nu utan att göra något, men det borde det göra).

Ett lösenord försvagas inte om man endast tar bort mellanslag före och efter lösenordet Det är dessutom inte rekommenderat att ha ett eller flera mellanslag före och/eller efter ett lösenord.

Det ska vara så enkelt och följsamt som det bara kan bli, att använda Enc Det ska vara såpass enkelt, att till och med en oteknisk person ska kunna använda tjänsten. Då ska man inte hålla på och skriva om meddelanden för att lösenordet innehåller mellanslag före och efter lösenordet Man ska även tänka på att alldeles för många personer är lata, ibland sjukt lata. Klicka/tryck, klistra in, läs. Inget krångel.

Citat från https://security.stackexchange.com/questions/32691/why-not-al... (första länken i ditt inlägg): "Leading and trailing spaces could be trouble for people who are loose with copy and paste."

Man måste komma ihåg att folk är lata.

Lösenord får innehålla mellanrum i Enc, men inte före och efter lösenordet. Den tredje länken i ditt inlägg, har en kommentar som jag håller helt och hållet med om. Sagda kommentar tog jag även en skärmdump på och inkluderade i ett av mina tidiga inlägg här: #20667451. Citerar den: "When typing their password for logging in, someone might copy and paste it, which adds an extra whitespace here or there. If you don't trim this in your login processing code, they won't be able to login even though to them the password is exactly the same."

Jag försöker inte blockera några tecken (förutom det som redan är sagt), och jag försöker inte heller göra något lösenord svagare genom att endast tillåta max antalet tecken. Från och med nästa uppdatering av Enc, kommer man vara tvingad till att ange minst 5 tecken i ens lösenord. Jag skrev om det i följande inlägg: #20669205. Och för att förklara varför: ett säkert lösenord ska egentligen inte innehåller färre tecken 14 (källa).

Så varför har jag valt minst 5 tecken? Jo, för att det finns inte många personer som klarar av/orkar att sätta ett lösenord manuellt på 14 tecken eller mer. Då kan man såklart använda sig av lösenordsgeneratorn som jag har på Enc, men många vill helst bara skriva in något de lätt kan komma ihåg eller nått annat jox. Helst ett som mottagaren redan kan, vilket skedde i går.

Jag träffade min bror i går och visade upp Enc för han och en till. Brorsan dök rakt in på att skriva in ett eget lösenord, utan att använda lösenordsgeneratorn, och hans lösenord var långt ifrån 14 tecken långt, men längre än 5 tecken.

Jag har tidigare skrivit i denna tråd, om att mellanrummen i ett lösenord trimmades bort som en nödåtgärd just där och då. Det blev "snabbt" åtgärdat, så från och med då började jag att trimma bort mellanrum före och efter ett lösenord.

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

Tack

Nä, allt krypteras och avkrypteras med hjälp av JavaScript Så jag får leta efter en sådan funktion för JavaScript.

Hehe, jodå. Jag använder htmlspecialchars() till min safetags-funktion för många av mina projekt

Nu ligger den nya uppdateringen uppe på enc.airikr.me. Om ni har besökt sidan tidigare och allt ser konstigt ut eller saker inte fungerar som de ska, rensa cacheminnet i webbläsaren och ladda om sidan.

Ändringslogg: https://codeberg.org/airikr/enc/commit/a5c883840afa5613e6ed46...

password.trim() != password

Jag får ursäkta mig. Ändringslogg: https://codeberg.org/airikr/enc/commit/e2fc9633bc67902c9c7a35...

Förutom minst en bugg ("Message not found" även om man inte har hunnit läsa meddelandet), anser ni att Enc är säker nog för fullskalig produktion?

Med "fullskalig produktion" menar jag om Enc är tillräckligt säker för att användas för till exempel företag och myndigheter. Att lösenordet kan skippas i adressen och bäddas in i krypteringssträngen tillsammans med det krypterade meddelandet, har jag noll aning om hur jag ska lösa. Hur ska webbsidan kunna avkryptera lösenordet när lösenordet krävs för att avkryptera allt?

Det är bara en undran jag har efter alla misstag och annat från min sida i den här tråden Kommer högst troligt inte ta bort "Enc is under development. Errors may occur." förrän kända buggar är åtgärdade.

Tack för förklaringen. Vid en snabb genomläsning av "dokumentationen", så måste man ange lösenordet i klartext för att kunna avkryptera något.

Jag kan förvisso lägga in bcrypt-strängen för lösenordet före meddelandets krypteringssträng i databasen (alltså, lösenordet hashat med bcrypt mellanslag meddelandet krypterat med AES). Kom på det nu när jag renskrev det här inlägget Ger det ett försök i morgon. Släktforskar nu.

Nä, det är samma här (som bevisat) Bra att kunna bolla med andra då.

Jag tog bort mitt förra meddelande. Läste om ditt inlägg mycket noggrannare. Att lösa det ni är ute efter kommer tyvärr kräva oerhört mycket tankekraft från min sida då jag måste lära mig hur man "kopplar upp" sql.js med async för att kunna använda await. Om jag känner mig själv rätt, så kommer det aldrig att ske.

Påminn mig gärna igen varför man "inte får" inkludera det hashade lösenordet i länken med hjälp av JavaScript

Kan inte uttrycka mig bättre än såhär på grund av att jag är sjukt hjärntrött med yrsel och tryck i huvudet.

Ja, jo, men man måste ju kolla om lösenordet är rätt? Det tog jag i går som att man måste kolla det när man försöker låsa upp 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);
    }
}

Tack för både kodexemplen och för förklaringarna Ska se vad jag kan göra åt detta. HMAC ser lovande ut.

Ända sedan minst 2 tillsägelser i tidigare inlägg i denna tråd, och rättade till källkoden, så har jag aldrig pratat om att kryptera eller avkryptera på servernivå Läxan lärd från mitt håll. Snälla, ta reda på fakta innan du säger något hädanefter. Om du trots detta tycker att jag har valt fel väg att gå, ladda hem källkoden, gör dina ändringar och gör sen en pull request.

Allt med säkerhetsfrågan på Enc är (vad jag vet) löst, förutom det där med var lösenordet ska lagras.

Det är endast lösenordet som hashas med bcrypt. Jag sökte runt på nätet och fann en fråga på security.stackexchange.com om vad för hashmetod man ska använda sig av för att på ett säkert sätt hasha ett lösenord. bcrypt listades som ett bra alternativ, så jag la in den metoden.

Länk till det svar som markerades som korrekt: https://security.stackexchange.com/questions/211/how-to-secur...

Läste nu dock "Input password size is limited to 51 characters", så jag måste fixa till det på något sätt, utan att begränsa lösenordets längd. En lösenordsfras med 6 ord + 1 siffra där mellanrummen är ersatta med ett bindestreck (-), kan bli över 51 tecken långa (54 tecken var ett jag kollade). Lösenordsgeneratorn på Enc ger en lösenordsfras med 4 ord + bindestreck istället för mellanrum, och ingen siffra. Till synes längsta lösenordet testat: 32 tecken. Så just nu i skrivande stund behöver jag inte stressa med att åtgärda detta.

Men varför valde jag bcrypt, förutom att det är ett bra alternativ? För att man ska inte kryptera lösenord med till exempel AES. Det är bara dumt. Kryptera ett lösenord med ett annat lösenord. Said whaaaat O.o

Sen gällande "snygga URLer". Varför? Bara inte länken är meterlång (*host* Google Maps *host*) så kvittar det ju hur länken ser ut. Bara den är organiserad och fin så kvittar det, eller hur?

Jag använder redan AES för att kryptera och avkryptera meddelandet och eventuella filer.

Hur då?

I början skickade jag lösenordet till servern och hashade det med password_hash(). Då sa folket här på forumet att jag inte ska göra det, utan hasha det via JavaScript, vilket jag lyssnade på och fixade till. Nu hävdar ni att jag skickar lösenordet till servern ändå, trots att jag endast använder JavaScript för det.

Det jag gör med lösenordet i dagsläget, är att jag hashar det med bcrypt, och petar in &pass=hashsträngen-för-lösenordet till länken som man delar till mottagaren - allt via JavaScript. Jag har tagit emot er kritik och förbättrat Enc så mycket jag bara kan, utifrån vad ni har skrivit.

Eller har JavaScript blivit det nya PHP (skicka data till servern och inte hantera det på klientnivå) utan att jag har fått veta om det?

Håller med.

Tack

sql.js är JavaScript som kopplar upp sig till en SQLite-fil på servern via JavaScript (med andra ord, på klientnivå). Jag tog upp det för jag inte kunde tänka klart den natten. Tack vare Pamudas kommer jag inte använda sql.js.

Woot?! Problemet är åtgärdat! Jag får ursäkta mig. Ändringslogg: https://codeberg.org/airikr/enc/commit/4dae27d5e2733f712e2c83...

Tack för att du upptäckte detta!

Som ni även kan se i share.js så har jag kommenterat bort en fetch(). Den ska ersätta $.ajax() i samma fil så fort jag har förstått mig på fetch().

Jag har alltid använt action och method i form-taggen, så de skrivs med av ren och skär vana Kan dock testa mig fram när jag väl förstår hur fetch() fungerar.