Czy tajemnice API powinny zostać zahartowane?

Question

To może brzmieć jak głupie pytanie, ponieważ hasła oczywiście muszą być mieszane i nigdy nie przechowywać oryginału.

Jednak w przypadku tajników interfejsu API zazwyczaj widzę je wyświetlane w sposób wyraźny podczas rejestracji.

Na przykład, jeśli przejdę do konsoli Google Api i zajrzę na stronę moich poświadczeń, mogę wyświetlić mój tajny klucz klienta, taki sam jak na Twitterze.

Z pewnością klucze interfejsu API są tak samo czułe jak hasła?

Czy to tylko dlatego, że od strony dostawcy możesz być pewien, że generowane jest wystarczająco silne hasło? Jeśli tak jest, to nie zapewnia żadnej ochrony, ponieważ twoja baza danych jest zagrożona.

A może dlatego, że jeśli używasz uwierzytelniania opartego na tokenach, robisz typ przydziału hasła, który wymaga wysyłania poświadczeń wraz z identyfikatorem klienta i tajnym kluczem lub odświeżaniem tokena, aby użytkownik już musiała zostać naruszona?

Answer 1

mogę sobie wyobrazić kilka możliwych odpowiedzi do tego:

• W niektórych przypadkach może być wymagane dla serwera mieć trwałe przechowywanie tekstu jawnego klucza API w celu spełnienia wymogów użyteczności (Google i Twitter jako przykłady).
• W niektórych przypadkach sam klucz API nie wystarcza, aby w ogóle wiele zrobić - dodatkowo trzeba mieć konto uwierzytelnione - i dlatego sam klucz API ma ograniczoną wartość (stąd mniej niż hasło) .
• W wielu przypadkach klucz API jest zakodowany na stałe w aplikacji klienckiej (szczególnie aplikacje mobilne, które prawie zawsze to robią) i dlatego nie ma sensu dodawanie dodatkowej ochrony po stronie serwera, gdy ten sam token może być trywialnie wyodrębniony z klienta.
• Branża bezpieczeństwa nie jest jeszcze dojrzała. Może, gdy hakerzy zaczną wyrzucać klucze API, takie pomysły mogą być traktowane poważniej.

BTW, bardzo poważnie podchodzę do ostatniego punktu. Prawda jest taka, że ​​wiele dobrych pomysłów nie staje się rzeczywistością, dopóki nie kryje się za nimi krytyczna masa wsparcia. Na przykład kiedyś blogowałem o pokrewnym temacie - protecting user confidential information by hashing it in the database, ale w taki sposób, że można go było odzyskać, kiedy loguje się prawowity użytkownik. Jako przykład posłużyłem Ashley Madison - w tym przypadku hakerzy byli bardziej po adresach e-mailowych , numery telefonów i adresy fizyczne niż hasła. Kiedy więc hakerzy wyłapali bazę danych, natychmiast otrzymali to, czego chcieli, i mogli mniej obchodzić szyfrowane hasła bcrypt (w rzeczywistości niektóre starsze hasła były kodowane tylko za pomocą MD5!) Niestety, takie pojęcia nie mają wystarczającej ilości pchnąć, aby stały się rzeczywistością. Nawet projekty internetowe o zerowej wiedzy są bardzo nieliczne w realnym świecie.