Jag använder vanligtvis en lösenordshanterare för att lagra och dela lösenord. Det finns många lösenordshanterare som har denna funktion.

Ett lösenord delas från ett konto till det andra, med meddelandet om delningen skickas via e-post till den andra personen, som kan välja att acceptera, avvisa, eller bara ignorera andelen. Kommunikationen av lösenordet är säker, medan aviseringen av resan går över mindre säkra kanaler som e-post, vilket använder styrkan i varje metod utan att kompromissa med säkerheten. Vissa produkter tillåter delning av lösenordet utan att lösenordet avslöjas för mottagaren. I så fall blir det möjligt att återkalla lösenordet.

Jag rekommenderar starkt att du använder en lösenordshanterare för alla dina lösenord. Vissa kommersiella är LastPass, 1Password eller Dashlane men det finns också möjlighet att vara värd för en själv om du inte vill lita på någon. En snabb google-sökning av "lösenordshanteraren" bör sätta dig på rätt spår.

En vanlig praxis är att skicka användaren ett inledande lösenord via e-post som endast är giltigt under mycket kort tid och behöver ändras omedelbart under den första inloggningen.

Detta är inte heller perfekt. En angripare med läsbehörighet till användarens e-postmeddelande kan fånga det ursprungliga lösenordet före användaren och använda det för deras räkning. Användaren kommer att märka så snart de försöker använda sitt ursprungliga lösenord. De skulle meddela administratören att lösenordet är fel, administratören undersöker och märker olaglig åtkomst. Men angriparen hade redan tid att komma åt kontot, så det kan redan vara skada. Men det är fortfarande bättre än att skicka ett permanent giltigt lösenord.

Det kräver också att systemet stöder detta. Så det är inte en allmänt tillämplig praxis.

När du inte litar på att din e-postleverantör ska hålla dina e-postmeddelanden hemliga (du använder gmail, en e-posttjänst som finansieras genom dataminering innehållet i din e-post och tjäna pengar på resultaten), då är e-postkryptering ett alternativ. Det finns den gamla gamla PGP, den mer moderna PEP, IETF-standarden S / MIME samt några icke-standardiserade proprietära lösningar. Det är det fina med standarder: Det finns så många att välja mellan! Men de har alla en sak gemensamt: De tar bara inte. Att få dina affärspartners att kryptera sin e-post i ett schema som du förstår kan vara en irriterande uppförsbacke.

Två faktorer

Det kanske inte är bokstavligen lämpligt för din situation, men ett rimligt sätt att skicka känslig data över kanaler som inte är helt säkra är att se till att två separata faktorer krävs för att få åtkomst till dessa data och att de skickas över olika kanaler. Till exempel har jag sett tillvägagångssätt där data skickas via e-post i en krypterad zip-fil, och lösenordet till dessa data skickas via SMS. På detta sätt kan varken någon som har det e-postmeddelandet eller någon som har åtkomst till din telefon komma till den känsliga informationen.

På liknande sätt kan det vara bättre om du skickar anslutningsinformationen via e-post och lösenordet kan sägas över telefon (speciellt om det är som en lösenfras) - men det valet är oftast upp till organisationen att skicka data (vem är förmodligen intressenten som behöver den informationen för att hållas konfidentiell ), inte till någon som bara tar emot den.

Om du litar på det finns onetimeecret (vilket är öppen källkod) för just detta syfte.

När du skickar känsliga personer info som lösenord och privata länkar via e-post eller chatt, det finns kopior av den informationen som lagras på många ställen. Om du istället använder en engångslänk fortsätter informationen för en visning vilket innebär att den inte kan läsas av någon annan senare. Detta gör att du kan skicka känslig information på ett säkert sätt och veta att den bara ses av en person. Tänk på det som ett självförstörande meddelande.

E-post är inte en bra mekanism för att dela lösenord i klartext med tanke på dess inneboende okrypterade karaktär.

Om lösenord delas på detta sätt bör tjänsten säkerställa att lösenordet ändras vid första inloggningen för att minska exponering (och för att låta dig upptäcka om någon har använt det stulna lösenordet), inte ett perfekt alternativ eftersom det fortfarande gör det möjligt för någon att dra nytta av möjligheten att komma åt webbplatsen men det är bättre än att inte veta att någon annan har lösenordet .

Eftersom detta inte ser ut att vara ett alternativ för dig med tanke på ditt svar på Schröders kommentar föreslår jag att du tittar på en mekanism som garanterar kryptering av lösenordet hela vägen mellan din kund och dig själv - antingen genom end-to-end-kryptering av e-postinnehållet eller med hjälp av en autentiserad och krypterad delningssida där lösenord för klartext kan krypteras. Tänk också om du är riktigt bekväm med andra människor (din kund, dina andra teammedlemmar) att känna till ditt lösenord, något som skulle bero på säkerhetskraven för applikationen du använder.

Den största risken här skulle vara vem, förutom dig själv, vet lösenordet. I ditt fall skulle detta vara, åtminstone:

• Personen i din kundorganisation som genererade lösenordet och mejlade det till dig
• Den som hanterar e-post infrastruktur mellan din kund och dig själv
• Alla som har nätverksåtkomst i någon av e-postvägarna mellan din kund och dig själv
• De andra gruppmedlemmarna som arbetar med samma konto och lösenord (framgår av ditt svar på Schroeders kommentar)
• Alla som kan ha tillgång till din brevlåda (t.ex. din kommentar om att lämna din e-postklient obevakad)

Om lösenordets enda mål är att undvika obehörig åtkomst till B2B-tjänsterna och du är bekväm med att andra känner till ditt lösenord kan du titta på kryptering för lösenordsfördelningen. Medan många SMTP-servrar implementerar kryptering för överföring av data mellan e-postserverhopp finns det ingen krypteringsgaranti, plus att e-post i sig inte krypteras så lösenordet kommer att finnas i klartext åtminstone under bearbetningen vid var och en av e-postöverföringshopparna (SMTP).

Detta innebär att du måste titta på end-to-end-kryptering för att säkerställa att lösenordet inte är tillgängligt för någon som snooping, till exempel PGP, S / MIME eller någon annan assymetrisk krypteringsbeskyddad teknik. Dessa skulle garantera konfidentialitet för lösenordet under transport, och du kan fortfarande använda e-post för dess distribution - med avvägningen av en svår inställning och driftskostnader.

Du kan kompromissa och använda något som en krypterad ZIP-fil eller Office-dokument med ett fördefinierat krypteringslösenord som delas via en säker kanal (t.ex. ett telefonsamtal), vilket minskar både den operativa omkostnaden och skyddet av lösenordet. På samma sätt skulle en molnhostad fil med lösenorden och skyddad med en säkert delad hemlighet ha samma fördelar / nackdelar.

Jag förstår inte varför du skickar lösenorden till dem?

Klienterna ställer in sitt önskade lösenord, du hash det, lagrar hash och ingen förutom klienten / hans lösenordshanteringsprogram vet det ursprungliga lösenordet (inte ens dig), och när de glömmer det, skickar du dem en återställningslänk.

Men om du verkligen måste skicka lösenordet till honom, föreslår jag att du skickar en länk till dynamiskt genererade webbsida som visar hans lösenord (endast en gång).

du måste tillfälligt lagra något liknande i din databas

  emailTocken char (32) lösenord varchar + - -------------------------------- + ----------------- - + | emailTocken | lösenord | + ---------------------------------- + -------------- ---- + | 202CB962AC59075B964B07152D234B70 | jhds7ytht_id | | CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874 # | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5) | | 2510C39011C5BE704182423E3A695E91 | 6 # hdyd98_jee | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e | + ---------------------------------- + -------------- ---- +  

och skicka ett e-postmeddelande till honom om att du bara exponerar e-postadressen. Klicka inte på lösenordet

  Hej, klient Följ den här länken för att se din lösenord https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543

på webbservern när någon begär denna länk gör du följande

1. välj lösenordet som har emailTocken tillhandahållen
2. ta bort posten från databasen

Nu kommer den första som begär denna länk att se något som

  Hej, klient, ditt lösenord är yeheb8cvddt5) OBS: VI RADERAR DETTA LÖSENORD FRÅN VÅRA SERVERAR, SÅ DU MÅSTE KOMMA / SPARA DET  

Om någon senare begär samma länk ser han något som

  Tyvärr, det här lösenordet finns inte eller har visats tidigare!  

Fördelarna med detta tillvägagångssätt med att skicka lösenordet i e-post:

1. lösenordet exponeras bara en gång för den första tittaren, inte för den som ser e-postmeddelandet senare .
2. om någon annan först tittade på lösenordet (en man-i-mitten) kommer den legitima användaren inte att kunna se det och kommer att be om hjälp, vilket får oss att veta att det finns något fel hände, bättre än någon annan ser det, och vi vet inte ens. Jag hoppas att ditt e-postagentprogram inte begär detta automatiskt av någon anledning :( .

nackdelarna med denna metod än att skicka lösenordet i e-post:

1. kräver webbserver
2. mer arbete än att bara skicka lösenordet i e-post lätt

Som jag berättade förut, ingen utom klienten borde veta lösenordet, och jag har aldrig provat detta tillvägagångssätt, men åtminstone är det bättre än att exponera lösenordet i klartext i en EMAIL som kan finnas på många datorer / servrar ett tag.

Jag har ett litet projekt som jag skapade som jag kallar "Secure Messaging Service" vilket gör att du kan skriva in ett meddelande och skapa en länk för att visa det meddelandet. När meddelandet har visats tas det bort från databasen. Det stöder till och med att skicka ett e-postmeddelande när meddelandet lästes!

Skriv in ett meddelande och tryck "skicka", vår server genererar en GUID baserad på uuidgenerator.net, en slumpmässig 8-tecken lösenfras baserad på passwordwolf.com (Som inte lagras i vår databas) och krypterar ditt meddelande med AES-256-CBC. Du får då en länk som innehåller GUID och lösenfras för att visa meddelandet (eller för att skicka till någon för att se meddelandet), så snart länken används kommer meddelandet inte längre att finnas i vår databas.

Du har nu möjlighet för vår tjänst att skicka ett e-postmeddelande när ditt meddelande läses av mottagaren. När du skickar din e-post krypterar vi den innan vi infogar den i vår databas med samma krypteringsmetod som ditt hemliga meddelande, inklusive samma lösenfras. Denna lösenfras lagras inte på vår server, den ges som en del av länken för att visa meddelandet.

Eftersom allt som skickas till vår server är krypterat med AES-256-CBC, och lösenfrasen finns bara i länken som tillhandahålls, det betyder att bara du och den du skickar länken till kan se meddelandet. Om någon annan vill se det, måste de tvinga det. Femtio superdatorer som kunde kontrollera en miljard miljarder (1018) AES-nycklar per sekund (om en sådan enhet någonsin skulle kunna tillverkas) skulle i teorin kräva cirka 3 × 1051 år för att tömma 256-bitars nyckelutrymmet. Vi har gjort vårt bästa för att dessa meddelanden inte ska kunna visas av någon annan än personen med länken, även om den personen har databasåtkomst, men vi ger inga garantier och ansvarar inte för skador som orsakas av att använda den här tjänsten.

Secure Messaging Service har också API-stöd, vilket innebär att du potentiellt automatiskt kan skapa och skicka ett e-postmeddelande till användare som registrerar sig med en länk för att se deras lösenord.

Så här data i databasen lagras, som du kan se, det finns inget sätt att återställa innehållet i meddelandet med hjälp av informationen i tabellen, eftersom det kräver en speciell lösenfras som bara läggs till länken som ges till dig när du skapar meddelandet och lagras inte i databasen.

Till att börja med är detta typ av dålig situation. Det låter som om du delar användarkonton. Ibland finns det inget bra alternativ till detta, men det bör inte användas med något särskilt känsligt eftersom det blir mycket svårare att granska användningen av resursen när det finns flera personer som loggar in under samma namn.

Om det är verkligen nödvändigt att ha flera personer som använder samma konton, då ska uppgifterna levereras personligen.

Det är nog inte praktiskt, så ditt nästa bästa alternativ är att skicka dem via fast telefon. (I de flesta länder åtminstone.) Fasttelefoner är relativt svåra att fånga upp och i de flesta länder är telefonföretaget förbjudet att lyssna utan domstolsbeslut. Statliga spionbyråer kanske lyssnar, men om de vill ha dina lösenord slår de dig bara tills du överlämnar dem ändå.

Runt samma säkerhetsnivå är krypterad e-post via GPG eller liknande. Det är lättare för tredje part att fånga upp och lagra data, men svårare för dem att läsa det tills de har tillräckligt med tid för att knäcka nyckeln. Se till att du byter lösenord med några år och se till att du inte använder samma formulärbokstav varje gång eftersom det gör det lättare att knäcka.

Om du inte kan få dem ombord med det så bokkod är din näst bästa insats. Behöver vara en bok som alla har och använder hela tiden ändå, så det kan vara lite knepigt. Typiskt format är ungefär som sidnummer-avsnittnummer-ordnummer. Låt lösenorden vara fyra eller fem ord och det fungerar bra. Eller stava det med den första bokstaven i varje angivet ord om det behövs.

Om en bokkod inte fungerar, så länge lösenordet inte innehåller några ord eller ordliknande strukturer räcker det med en enkel ersättning eller transponeringskryptering för kryptogrammen i tidningen för att hålla alla utom mest beslutsamma angripare. Men lösenordet måste bestå av slumpmässiga tecken, annars kommer statistisk analys att göra det kort och du måste fortfarande leverera krypteringsnyckeln via en säker kanal. Uppenbarligen med den här metoden krypterar du bara lösenordet för att begränsa din attackyta och helst inte nämna alls det faktum att du har krypterat det i resten av e-postmeddelandet. All diskussion om att lösenordet är krypterat och hur det måste ske via en säker kanal.

Det finns ett typiskt användningsfall för distribuerade utvecklingsteam där SysOps och TeamMembers skapar referenser till en resurs (DataBase, service, server) och måste kommunicera dem till teamet. OM du lägger till en ny medlem i teamet:

• Du kan inte bara hash lösenordet.
• Du kan inte bara återställa lösenordet för att inte sluta fungera för resten av teamet.

Vi använder en distribuerad lösenordshanterare. Detta gör att vi kan lägga till ett nytt lösenord och dela det med individer eller grupper. Du kommer att få ett e-postmeddelande som "BOFH-1 delade lösenordet" JenkinAdmin "". Du måste logga in för att se det riktiga lösenordet som kommer att resa genom https.

Ett centraliserat verktyg kan vara en överdrift för vissa scenarier eftersom det tvingar dig till viss installation och konfiguration. Det är bra om hela din avdelning använder den för att uppdatera den. Endast en person behöver uppdatera referensen i lösenordshanteraren. Vi använder ett open source-verktyg men specifika program diskuteras bättre i Programvarurekommendationer

Korrekt, det är osäkert att skicka ett lösenord i ett e-postmeddelande.

Ett säkert initialt kontoprotokoll är:

Skicka användaren en engångsanvändning, utgången hyperlänk och tillåt användaren för att ställa in sitt ursprungliga lösenord från den länken. Kontrollera sedan eventuellt att användaren har ställt in den andra faktorn. Kontrollera sedan eventuellt användarens identitet på något annat sätt (videosamtal?) Slutligen, ge användarens konto den åtkomst de behöver.

Jag föreslår att du använder Signal för att skicka och ta emot lösenord. Det är en krypterad chattapp från slut till slut.

Signalmeddelanden och samtal är alltid krypterade och noggrant konstruerade för att hålla din kommunikation säker. Vi kan inte läsa dina meddelanden eller se dina samtal, och ingen annan kan heller.

Inget e-postmeddelande är inte säkert eftersom även om du använder SSL på dina e-postservrar finns det ett register över meddelandet på serverns disk som kan läsas av en administratör. Endast PGP / GPG eller SMIME-krypterad e-post är säker.

Någon lade till följande i mitt svar. Jag har inte hört talas om dem så kan inte rekommendera.

Ovanpå Signal - ett annat krypterat alternativ för att utbyta meddelanden kan användas, som inte kräver att du bekräftar ditt ID genom att klicka på länkar eller tillhandahålla e-post etc. Det är också flera plattformar vilket är mycket viktigt. Det är

1. för Android: Konversationsapp
2. för Linux och Windows: Gajim-app

Den kan använda antingen PGP- eller OMEMO-kryptering - plug-in kan behöva installeras separat.

Det finns också en annan metod, förmodligen den bästa i din situation.

Det kräver att du har en webbplats med SSL och på en webbplats och inbäddad låda. Någon kan skriva ett meddelande i den rutan och vid sändning ska meddelandet krypteras med [dvs] PGP offentlig nyckel som bara kan dekrypteras automatiskt på din PC-e-post.

Be dem istället ta upp telefonen och ringa dig. Användning av kommunikation utanför bandet minskar avsevärt sannolikheten för att en avlyssnare får tillgång till din information. Detta beror delvis på att det inte är osannolikt att en angripare skulle ha äventyrat ditt e-postsystem eller ditt telefonsystem, men oddsen för att de skulle äventyra båda är låga. om du kan dela upp den viktiga informationen (t.ex. användarnamn i e-post, lösenord via telefon osv.) blir det bara svårare för angriparen, relativt den ökning av arbetet som krävs av dig.

Om din e-post är förinställd av företaget så är en lösning att inte ha ett lösenord alls (lösenordet är sådd med en lång, komplicerad etc. sträng som ingen vet).

Du begär sedan en ny (även om funktionen "Glömt lösenord"), som skickar en återställningslänk till din e-post.

Det goda telefonsamtalet är en beprövad metod.

Bortsett från detta är ett SSH-handslag en bra metod ...

Både du och mottagaren genererar en SSH-nyckel. Du skapar ett lösenord och krypterar lösenordet med din nyckel. Du skickar krypterat lösenord till klienten. De lägger till ytterligare kryptering i ditt meddelande med hjälp av nyckeln. Sedan skickar de tillbaka det dubbelkrypterade meddelandet. Du dekrypterar detta meddelande och lämnar bara lösenordet krypterat av mottagarens nyckel. Du skickar tillbaka detta meddelande. De dekrypterar det med sitt lösenord för att få lösenordet. På så sätt berör okrypterad data aldrig webben.

OAuth är alternativet för att komma åt system från tredje part utan kravet på att konfigurera lösenordsautentisering i nämnda system och eliminerar behovet av att utbyta lösenord. Naturligtvis skulle det kräva att systemen stöder OAuth, vilket inte alltid är fallet.

Det första jag tänker på är asymmetrisk kryptering (t.ex. GPG). Detta kan vara särskilt användbart utan att komplicera saker.

Hitta eller ställa in en nyckelserver och låt alla dela sina offentliga nycklar. När du behöver dela något känsligt för en viss mottagare kan du sedan ta tag i hans nyckel och kryptera innehållet. Ingen annan känner till det ursprungliga innehållet förutom mottagaren.

Ett exempel på e-postmeddelande skulle bli:

Hej iBug,

Här är din inloggningsuppgifter till Informationssäkerhetsstackutbyte. Den krypteras med din nyckel DEADBEEF som finns på vår företagsnyckelserver.

  < GPG Krypterat meddelande >  

Du kan använda SendPass ( https://sendpass.app)

Enligt min mening är de två största riskerna med att skicka lösenord i ren text att de kan ligga i arkiv, loggar eller fortfarande i användarens brevlåda, och den andra är avlyssning av lösenordet och den faktiska mottagaren som inte känner till detta (och därför inte meddelar administratören).

För att hantera dessa risker har jag skapat en gratis applikation som du kan använda för att skicka en engångskod som kan användas av mottagaren för att hämta lösenordet. Jag har publicerat SendPass för att hjälpa andra, särskilt icke-tekniska personer, men det kan också vara till nytta för dig.

SendPass erbjuder dig ett gratis, enkelt och säkert sätt att dela lösenord. SendPass fungerar genom att generera en unik engångskod som du kan skicka till din mottagare. Koden kan bara användas en gång, varefter lösenordet raderas omedelbart.