Wprowadzanie hasła w wywołaniu interfejsu API REST

Załóżmy, że mam interfejs API REST, który służy również do ustawiania / resetowania haseł. Załóżmy również, że działa to w przypadku połączeń HTTPS. Czy jest jakiś dobry powód, aby nie umieszczać tego hasła w ścieżce wywołania, powiedzmy też, że zakoduję je w BASE64?

Przykładem może być zresetowanie hasła takiego:

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

Rozumiem, że BASE64 nie jest szyfrowaniem, ale w tym przypadku chcę tylko zabezpieczyć hasło do surfowania po ramieniu.

Dobry serwer rejestruje wszystkie wysłane do niego żądania, w tym adresy URL (często bez części zmiennej po „?”), Źródłowy adres IP, czas wykonania ... Czy naprawdę chcesz, aby ten dziennik (potencjalnie czytany przez szeroką grupę administratorów) zawierał krytycznie bezpieczne informacje jako hasła? Base64 nie stanowi dla nich przeszkody.

To, co proponujesz, nie jest ani bezpieczne, ani RESTful.

@Netch wspomniał już o problemie z logami, ale jest też inny problem polegający na tym, że wyświetlasz hasła wysyłane przez HTTP, dzięki czemu przechwytywanie haseł za pomocą dowolnego podsłuchu lub ataku typu man-in-the-trywialnego jest banalne.

Kiedy wykonujesz żądanie GET przy użyciu REST, różne elementy w adresie URL reprezentują elementy o drobniejszych ziarnach. Twój adres URL brzmi, jakbyś zwrócił NEWPASSWD część OLDPASSWD, która jest częścią hasła resetowania. To nie ma żadnego sensu semantycznego. GET nie powinny być używane do zapisywania danych.

Powinieneś robić coś takiego:

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

POST, ponieważ piszesz dane, a https, ponieważ nie chcesz, aby były wąchane.

(To naprawdę niskie bezpieczeństwo. Absolutne minimum, które powinieneś zrobić.)

Proponowany program ma problemy w kilku obszarach.

Bezpieczeństwo

Ścieżki URL są często rejestrowane; stawianie niepasujących haseł na ścieżce to zła praktyka.

HTTP

Informacje o uwierzytelnieniu / autoryzacji powinny pojawić się w nagłówku autoryzacji. Lub potencjalnie, w przypadku rzeczy opartych na przeglądarce, nagłówek Cookie.

RESZTA

Czasowniki, takie jak resetpasswordw adresie URL, są zazwyczaj wyraźnym znakiem niereprezentatywnego paradygmatu transferu stanu. Adres URL powinien reprezentować zasób. Co to znaczy GET resetpassword? Lub USUŃ?

API

Ten schemat wymaga zawsze znajomości poprzedniego hasła. Prawdopodobnie będziesz chciał pozwolić na więcej przypadków; np. hasło zostało utracone.

Możesz użyć uwierzytelniania podstawowego lub szyfrowanego , które są dobrze zrozumiałymi schematami.

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

Nie umieszcza ultra wrażliwych informacji na ścieżce i postępuje zgodnie z konwencjami HTTP i REST.

Jeśli musisz zezwolić na inny tryb autoryzacji (np. Token wysłany przez zweryfikowany kanał w celu zresetowania hasła), możesz po prostu użyć innego nagłówka autoryzacji bez konieczności zmiany czegokolwiek innego.

Poza bezpieczeństwem problem polega na tym, że nie jest to podejście RESTful.

OLDPASSWDi NEWPASSWDnie oznacza niczego w hierarchii zasobów, a co gorsza, operacja nie jest idempotentna.

Możesz więc używać tylko POSTjako czasownika i nie powinieneś dołączać dwóch haseł do ścieżki zasobów.

Problem polega na unikaniu haseł w postaci zwykłego tekstu w żądaniach. Istnieją dwie opcje spełnienia restrykcyjnych wymagań usługi internetowej.

1. Hashowanie po stronie klienta

• Domyślam się, że przechowujesz swoje hasła, takie jak np. Hash (hasło + sól)
• Możesz haszować nowe hasło solą po stronie klienta
• Oznacza to: Utwórz nową sól po stronie klienta, utwórz hash, np. Hash (newPassword + newSalt)
• Wyślij nowo utworzony skrót i sól do spokojnej usługi internetowej
• Wyślij stare hasło również jako skrót (oldPassword + oldSalt)

2. Szyfrowanie

• Utwórz zasób „klucza jednorazowego” (otk) dla użytkownika takiego jak / otk / john
• Ten zasób zwraca bezpieczny losowy unikalny klucz jednorazowy, np. KbDlJbmNmQ0Y0SmRHZC9GaWtRMW0ycVJpYzhMcVNZTWlMUXN6ZWxLdTZESFRs i unikalny identyfikator, np. 95648915125
• Twoja spokojna usługa internetowa musi przechowywać ten przypadkowy otk do następnej bezpiecznej komunikacji z ID 95648915125
• Zaszyfruj swoje nowe i stare hasło za pomocą otk, np. AES (ze względów bezpieczeństwa powinieneś użyć dwóch oddzielnych otków dla starego i nowego hasła)
• Wyślij zaszyfrowane hasła do zasobu zmiany hasła o identyfikatorze 95648915125
• Jedna kombinacja otk i ID może działać tylko raz, więc musisz usunąć tę kombinację po zmianie hasła
• Możliwa lepsza opcja: Wyślij bieżące / stare hasło przez Basic-Auth.

Uwaga: HTTPS jest wymagany dla obu opcji!

Jakie są funkcje operacji resetowania hasła?

1. To coś zmienia.
2. Istnieje wartość, która jest ustawiona.
3. Tylko niektóre osoby mogą to robić (użytkownik, administrator lub jedno lub drugie, być może z różnymi zasadami, jak to zrobić).

Punkt 1 tutaj oznacza, że ​​nie możesz użyć GET, musisz albo POST wysłać coś reprezentującego operację zmiany hasła do identyfikatora URI reprezentującego zasób, który obsługuje zmiany hasła, lub PUT coś reprezentującego nowe hasło do identyfikatora URI reprezentującego hasło lub reprezentującego coś (np. użytkownika), którego hasło jest funkcją.

Zazwyczaj POST, zwłaszcza dlatego, że może być niewygodne WYKŁADANIE czegoś, czego nie możemy później uzyskać i oczywiście nie możemy uzyskać hasła.

Punkt 2 będzie zatem danymi reprezentującymi nowe hasło, w tym, co jest POST.

Punkt 3 oznacza, że ​​będziemy musieli autoryzować żądanie, co oznacza, że ​​jeśli użytkownik jest bieżącym użytkownikiem, będziemy potrzebować aktualnego hasła, aby nam je udowodnić (choć niekoniecznie otrzymamy aktualne hasło, jeśli np. Wyzwanie oparte na haszowaniu służyło do udowodnienia znajomości go bez wysyłania go).

URI powinien zatem być podobny do <http://example.net/changeCurrentUserPassword>lub <http://example.net/users/joe/changePassword>.

Możemy zdecydować, że chcemy otrzymać aktualne hasło w danych POST, a także w ogólnym mechanizmie autoryzacji.