Potrzebuję w swoim API przechowywać hasła do skrzynek pocztowych użytkowników. W jaki sposób mogę to zrealizować aby wszystko było odpowiednio zabezpieczone?
Hasła te będę musiał później "odzyskać" w celu ich dalszego wykorzystywania -> logowanie na skrzynkę w celu wysłania wiadomości wtedy gdy będzie to potrzebne.
Całość będzie oparta o PHP i mySQL.
Będę wdzięczny za każdą sugestię.
Jeśli mówimy o takich typowych przykładach wysyłki email przez jakiś serwer SMTP, to zwróć uwagę, że np. gmail i outlook nie pozwolą ci wysłać wiadomości jak po prostu wpiszesz login i hasło uzytkownika w kodzie programu, będziesz musiał użyć wygenerowanego klucza do skrzynki. Ma to związek ze zwiększeniem zabezpieczeń, 2FA itd.
Przykładowy wątek na stack: https://stackoverflow.com/questions/78195488/google-smtp-with-app-password-suddenly-stopped-working-march-19-2024
Co do samego trzymania w bazie, to po prostu ustawiłbym sobie klucz szyfrujący w appsettings i na jego podstawie szyfrował dane użytkowników przed zapisem w bazie, a potem po pobraniu z bazy odszyfrowywał na moment by wstawić do wysyłki email.
Hasłeł się nie szyfruje tylko hashuje.
https://stackoverflow.com/questions/326699/difference-between-hashing-a-password-and-encrypting-it
Rozumiem, że to użytkownik podaje ci dane dostępowe do swojego maila, te dane chcesz zapisać do bazy danych, a następnie twój program używa tych danych, żeby połączyć się z serwerem SMTP użytkownika w jego imieniu i cośtam wysłać jako on.
Brzmi to jak słaby pomysł - ale np. taki Gmail pozwala na ściąganie poczty z innych kont. I dokładnie tak trzeba zrobić - podać Googlowi dane dostępowe swoich skrzynek. Ja bym się z tym nie czuł komfortowo, ale wiem że wielu ludzi tak robi.
Ogólnie szyfrowanie haseł jakimś szyfrem symetrycznym prawdopodobnie zaliczy wymaganie "jest szyfrowane" jeśli masz takie wymaganie, aczkolwiek to obroni cię tylko w przypadku wycieku bazy. Jeśli ktoś ci wbije na serwer i np. będzie mógł wykonać jakiś skrypt, to sobie ten klucz wyciągnie i tak.
A możesz napisać coś więcej o problemie bo może rozwiązujesz jakiś problem którego nie ma.
@Adin
@kelog
@lion137
@MrówkaBiegowa
Tworzę api do szeroko rozumianego zarządzania firmą.
Jeden z modułów bazuje na wysyłce maili. To co będzie wysyłane i to co będzie załączane zależy od innych modułów aplikacji.
Czyli tam tworzymy szablon html, wskazujemy odbiorcę, dodajemy załączniki, które są generowane przez konkretne moduły (np plik ofertowy PDF).
Jednym kliknięciem to się wysyła. Nie trzeba się logować na skrzynkę, dodawać załączników itp...
Klient nie korzysta z Gmaila czy tam Outlooka. Z Outlookiem mam doświadczenie i tam jest o tyle fajna sprawa, że tam logujemy się bez hasła (tokenem) i w zależności od nadanych uprawnień w microsoft graph API mogę wysyłać jako dowolny użytkownik w obrębie danego konta Outlook.
Niestety tutaj klient korzysta z poczty usługodawcy hostingu (czyli nazwa/home/cyber-folks itp).
Muszę więc przechowywać hasło do skrzynki danego użytkownika i w razie potrzeby (gdy korzysta z modułu wysyłki) pobrać hasło i przy jego pomocy zalogować się do skrzynki w celu wysłania maila.
W bazie na pewno nie może być hasło jako plaintext, ale muszę w takiej formie je otrzymać podczas procesu logowania SMTP
No to moim zdaniem nie ma innej opcji, niż po prostu zaszyfrowanie hasła użytkownika jakimś algorytmem i dodanie go do bazy.
Pobierając go z bazy odszyfrujesz je na chwilkę i wstawisz w kodzie do miejsca logowania SMTP.
Szczerze to brzmi tak tradycyjnie jak wiele poradników z neta w stylu "jak wysyłać emaile przez smtp w kodzie java/python/c#/ itd.".
Po prostu szyfruj hasło jeśli masz je trzymać w bazie i ustaw silny klucz do szyfrowania.
Co do domen no to musisz popróbować na żywym organizmie, najlepiej utwórz sobie testowe konta i sprawdź czy twój kod zadziała.
Tak jak pisałem gmail i outlook działały w ten sposób, ale przestały ze względów bezpieczeństwa. Może cyber folks działa nadal, a może kiedyś też umocnią zabezpieczenia.
Załóż testowe konto i spróbuj jak działa twój kod, a zaszyfrowane hasła możesz trzymać w bazie. Może ktoś ma lepsze rozwiązanie.
Dzięki silnym kluczom szyfrowania nawet jeśli nastąpiłby atak na bazę to zdążysz poinformować klientów o incydencie, by zmienili sobie hasła na skrzynkach.
Jeden z modułów bazuje na wysyłce maili. To co będzie wysyłane i to co będzie załączane zależy od innych modułów aplikacji.
Czyli tam tworzymy szablon html, wskazujemy odbiorcę, dodajemy załączniki, które są generowane przez konkretne moduły (np plik ofertowy PDF).
Jednym kliknięciem to się wysyła. Nie trzeba się logować na skrzynkę, dodawać załączników itp...
A nie prościej po prostu założyć oddzielne konto serwisowe do tych celów?
A nie może podać tego hasła przy wysyłaniu maila? Przechowywanie.hasal zawsze budzi podejrzenia itp. I niebezpieczeństwo.
To brzmi jak straszny pomysł od strony bezpieczeństwa, po prostu wysyłaj te maile ze swojego konta, lub konta dynamicznie wygenerowanego dla usera tak jak robią to niektóre strony społecznościowe czy np github gdy dostajesz wiadomość prywatną i idzie mail z adresu user+425345@domain.com i nawet można obsłużyć odpowiedzi na takiego maila i przekazywać je dalej na właściwą skrzynkę.
Proszenie o hasło jest dziwne, równie dobrze po prostu możesz userów spytać żeby sobie zmienili hasło na takie jakie im wygenerujesz na podstawie jakiegoś hasha i w ogóle nie musisz ich wtedy nigdzie przechowywać. Ale to słaby pomysł, tak jakby oddać klucze do swojego auta żeby dostać dostawę pizzy
No i w ogóle nie musisz się logować na konto żeby wysłać z niego maila, gmail na przykład może wysłać maila z dowolnego przypiętego konta po weryfikacji i zwyczajnie podmienia pole From, zaufane serwery pocztowe mogą sobie tak robić. Ja mam nawet możliwość wysyłania w ten sposób maili z domen które już dawno nie istnieją.
Jeśli to jakieś wewnętrzne skrzynki firmowe to twój serwer mailowy może podać się za dowolną osobę bez żadnego hasła.
Poproś o konfigurację "sand as" na serwerze poczty. Jeśli masz serwer poczty na tym samym hostingu można też wyłączyć autoryzację dla localhost.
Trzymanie haseł w tym momencie nie ma sensu. Przy każdej zmianie hasła użytkownik musi je wpisywać.
Czy ktoś może odpowiedzieć na pytanie zadane w tym temacie?
Na razie to każdy rzuca na prawo i lewo swoimi pomysłami/sugestiami (nie mówię, że są one złe czy coś), które akurat w moim przypadku się nie sprawdzą.
Tematem jest jak przechować takie dane w bezpieczny sposób, a nie konfigurowanie środowiska pocztowego usługodawcy.
Każdy kto choć raz tworzył cokolwiek dla zewnętrznego podmiotu wie jak taka współpraca wygląda. Często klient ma swoje widzimisie i w żaden sposób nie da się go przekonać na inne rozwiązanie.
Już masz odpowiedzi:
Temat chyba wyczerpany.
Użyłem dwóch kluczy. Jeden globalny dla API i drugi dla konkretnego użytkownika. Każde hasło traktuję obydwoma przed szyfrowaniem/deszyfrowaniem.
@NewUser2k13 - ok, jest to jakaś opcja, ale powiedz mi proszę - co daje podejście z dwoma kluczami? Co zyskujesz dzięki temu, że masz klucz globalny oraz indywidualny?
W sensie - tak, jak Ci ludzie pisali wcześniej, poprzez szyfrowanie (jednoetapowe i z jednym kluczem) już się i tak zabezpieczasz przed wyciekiem bazy - jeśli gdzieś pójdzie w świat, to nikt haseł nie odczyta
ALE
w przypadku dostępu do kodu źródłowego (albo do serwera - jeśli np. mówimy o jakimś PHP czy innym języku/technologii, który nie jest kompilowany), ewentualnie bawiąc się w inżynierię wsteczną albo odczytując pamięć podczas używania aplikacji - można poznać sposób szyfrowania i użyte klucze (albo trzymane w pamięci hasła już w postaci odszyfrowanej), więc nawet jakbyś to szyfrował 20 razy pod rząd - w mojej ocenie wiele to nie zmieni. CHYBA że będziesz oczekiwać od użytkownika podania tego swojego osobistego klucza za każdym razem, gdy będzie korzystać z aplikacji. Tylko to będzie mega upierdliwe dla użytkownika. Zresztą - wtedy równie dobrze może po prostu podawać hasło do maila zamiast prywatnego klucza szyfrującego.
NewUser2k13 napisał(a):
Całość będzie oparta o PHP i mySQL.
Będę wdzięczny za każdą sugestię.
Najszybciej - przechowywuj hasze.
Najbezpieczniej i profesjonalnie - zaproponuj integrację third-party providera który zapewni taką usługę.