Loading...

Google vs AUTHY – 2FA’da Güvenlik Savaşları

Ulaş Fırat Özdemir – [email protected]

Bu makale daha önce Arka Kapı Dergi’nin, 6. Sayında yayımlanmıştır.


Merhaba, bu yazımızda yeni nesil internet güvenliğini sağlamayı amaçlayan iki aşamalı doğrulama (2FA) teknolojisi ve bu teknolojiyi kolaylıkla kullanmamızı sağlayan en yaygın iki uygulamadan bahsedeceğiz. 

Çok etkenli doğrulama (MFA), sisteme giriş ve yetkilendirme öncesinde kullanıcının doğrulanması için iki ya da daha fazla kanıt gerektiren güvenlik modelidir. Bu modelde kanıtlar üç ana kategoriye (faktör) ayrılır ve her kanıtın farklı kategoriden olmasına özen gösterilir. Bu sayede kullanıcı birden çok doğrulama aşamasından geçmekte ve bağımsız aşamaların kullanılması sonucu bir aşamanın yarattığı güvenlik riski diğer aşamaları etkilememektedir. Üç kategori aşağıdaki gibi sıralanabilmektedir,

Bildiğiniz bir bilgi:

Buradaki asıl amaç, sistemi kullanmak istediğiniz süre boyunca daima hatırlamanız gereken, size ait ve gizli bir bilginin kullanılması ile doğrulama yapmaktır. Bu bilgi bir parola, kullanıcı adı, PIN, PUK, imza, güvenlik sorusu ve cevabı olabilir.

Sahip olduğunuz bir araç:

Buradaki amaç, sadece size ait olan, kişiye özel tasarlanmış ve sistemin diğer kullanıcılarının sahip olamayacağı fiziksel bir aracın kullanılması ile doğrulama yapmaktır.

Bu araç bir telefon (uygulama), akıllı kart, RFID kartı , OTP cihazı ve e-imza şeklinde elektronik olabileceği gibi aynı zamanda QR kod, kabartma ve farklı boyalar (para) gibi elektronik olmayan yöntemler de kullanılabilmektedir. Bir de ek olarak telefon hattı (SMS) ve arama ile doğrulama gibi farklı kanallar sayesinde doğrulanan bilgiler de bu aracın tanımına dahildir.

Size ait olan bir özellik:   

Buradaki amaç, size ait olan ve diğer kullanıcılara göre farklılık gösteren bir fiziksel özelliği kullanarak doğrulama yapmaktır.

Bu özellik parmak izi, retina, avuç içi, el damarları, kemik ve yüz yapısı gibi yapısal özellikler olabileceği gibi klavye kullanımı, yazım biçimi, yazı stili, konuşma şekli (aksan ve ton) ve benzeri şekilde düşünerek öğrendiğimiz ama doğal olarak uyguladığımız davranışsal bilgiler de kullanılabilmektedir

http://biometrics.mainguet.org/types/fingerprint/fingerprint_sensors_physics.htm

İki etkenli doğrulama ise en yaygın kullanılan çok etkenli doğrulama yöntemidir. Bu yöntem ile iki farklı kategoriden (faktör) iki adet kanıt kullanımı ile doğrulama sağlanır. İki aşamalı doğrulama ile iki etkenli doğrulama çok karıştırılan kavramlardır bu nedenle küçük bir açıklama yapmak gerekirse, iki aşamalı doğrulama kullanıcıdan iki farklı kanıt talep eder. Bu kanıtlar farklı faktörlerden (göz taraması ve parola) olabileceği gibi aynı faktöre (parmak izi ve göz/retina taraması) ait de olabilir. İki etkenli doğrulama ise iki kanıtın da birbirlerinden farklı faktörlere ait olmasını gerektirir. İki etkenli doğrulamada bir faktörde oluşabilecek zafiyetler öteki faktörlerden olabildiğince izole tutulmaya çalışılır. Bu durumda iki etkenli doğrulama iki aşamalı doğrulamadan daha güvenlidir.

İki etkenli doğrulamayı sistemlerine entegre eden birçok firma bulunmakta. Bu firmaların bir kısmı kendi çözümlerini geliştirmiş olsa dahi büyük bir çoğunluğu 3. parti uygulamalara güvenmektedir. Rakipleri tanımadan önce sahanın bir diğer ucunda bulunan Apple’ın yaklaşımını da incelemekte fayda var. 

https://blog.elcomsoft.com/2016/04/apple-two-factor-authentication-vs-two-step-verification/

Apple ilk olarak 2013 yılında getirdiği iki adımlı doğrulama özelliği sayesinde kullanıcıların Apple ID bilgileri kullanılarak yapılabilecek işlemleri daha da güvenli kılmayı amaçlamıştır. Bu özelliği kullanan kullanıcılar için iCloud ve Apple ID girişi esnasında ya da yeni bir cihaz ile yapılan ilk alışverişte ikincil bir doğrulama adımı gerekli hale getirilmiştir. İkinci adımdaki güvenlik kodları ise aşağıda belirtilen yöntemlerden birisi ile alınabilmektedir.

  • Güvenilir bir cihaza yapılan bildirim,
  • Kayıtlı bir numaraya SMS ya da arama,
  • Çevrimdışı kurtarma anahtarı,
  • Uygulamaya özel parolalar.

İki adımlı doğrulama ise Apple cihazlarından ya da My Apple ID üzerinden aktif hale getirilebilmektedir.

Apple, 2015 yılında iOS 9 ve OS X El Capitan ile birlikte yayınlanan iki faktörlü doğrulama ile iki adımlı doğrulama yöntemini geliştirerek kullanıcılara daha güvenli bir alternatif sunmayı amaçlamıştır. Bu doğrulama yöntemi iOS 9 ve sonrasındaki cihazlar için geçerlidir ve eski cihazlar bu özellikten faydalanamamaktadır. İki faktörlü doğrulamada ise aynı faktörü kullanmaları nedeniyle çevrimdışı parolalar ve kullanım karmaşıklığı yaratması nedeniyle uygulama bazlı parolalar bulunmamaktadır. Bunun yerine çevrimdışı, zaman tabanlı kod yaratıcı (kodmatik) ve 6 haneli kimlik doğrulama kodu uygulamaya koyulmuştur. 6 haneli kodun paroladan çok farklı olmadığını duyar gibiyiz. Evet, çünkü 6 haneli kod desteği eski cihazlar için sunulmuştur. iOS 9’dan eski cihazlarda giriş yapılırken bu özellik aktif ise ekstra 6 haneli bir kimlik doğrulama kodu talep edilmektedir. Bu özelliğin aktif edilmesi için iki adımlı kimlik doğrulama özelliğinin pasif hale getirilmesi gerekmektedir ve özellik aktifleştirildiğinde hesabınıza kayıtlı eski bir cihazınız bulunmaktaysa, eski parola ile birlikte 6 haneli kod girilmesinin gerekli olabileceğini belirten bir uyarı ile karşılaşmaktasınız.

Apple’ın yaklaşımından sonra konunun uygulanması konusunda fikir sahibi olmamızın şerefine rakipleri ve bize sundukları avantajları tanıyalım. 

Mavi köşede, sunduğu hizmetler sayesinde internet üzerinde baskın bir güç haline gelen Google ve uygulaması Google Authenticator bulunmakta. Bu uygulama, kullanılan servislere zaman bazlı OTP (TOTP) ve Hmac bazlı OTP (HOTP) sağlayarak giriş yapmanızı amaçlar. 

Bu sayede Google Authenticator (ya da aynı algoritmayı çalıştıran başka bir uygulama) olmadan hesabınıza giriş yapamazsınız. HOTP algoritmasında uygulama ve web servisi bir gizli veri (secret) ile bir sayaç (counter) verisini ortak bir şekilde paylaşırlar. Uygulama her yeni kod ürettiğinde sayaç iki taraflı olarak arttırılır ve bu sayede senkronizasyon sağlanır. HOTP sistemlerinin en kritik problemlerinden biri ise sayaç değerinin senkronizasyonudur. Sayaç değeri iki taraf için de aynı olmalıdır, aksi taktirde üretilen kodlar birbiri ile uyuşmaz. 

Ağ veya uygulama kaynaklı bir hatadan dolayı ortaya çıkabilecek ortak sayaç problemlerine karşı RFC4226 dökümanının 7.4 bölümü bir açıklama getirmiştir. Bu bölüme göre kontrol eden taraf bir ileri bakış (look ahead) değerine sahip olmalıdır. Bu değer sayesinde sayaç değeri ve sonrasında gelen ileri bakış kadar değer kullanılarak HOTP hesaplanır ve eğer sonraki değerlerden birisi eşleşiyor ise senkronizasyon sağlanmış olunur. Bu değerin çok yüksek verilmesi ya da sınırsız olması, her eşleşmeyen kod için kontrol eden tarafın uzun bir süre HOTP hesaplaması anlamına gelmektedir ve bu da DoS/DDoS saldırılarına yol açmaktadır. 

Eğer ileri bakış değeri çok kısa tutulursa bu sefer de senkronizasyon hataları ortaya çıkabilmektedir. Bu nedenle ileri bakış değeri dikkatlice seçilmelidir. HOTP Senkronizasyon problemlerinin farklı bir çözümü ise, sıralı bir şekilde verilen birkaç HOTP değerinin girilmesidir. Bu durumda doğrulayan taraf aldığı sıralı HOTP değerlerini kendi ürettiği değerlere karşı kontrol eder ve doğru sırayı tahmin ettikten sonra sayaç verisinin eşleşmesini sağlar. TOTP algoritmasında ise HOTP ye göre tek fark sayaç değeridir. Sayaç yerine zaman verisi kullanılır. Bu zaman verisi iki sistem için de ortak ve hassas olmalıdır, bu nedenle hesaplamalarda genellikle Unix Epoch zamanı kullanılır. İki sistem de NTP protokolü ile zaman verisini güncel tutmalıdır. Sağlanan kod her seferinde değişmek yerine zamana bağlı (ör. 30 saniyede bir) değişim gösterir. Bu nedenle Unix Epoch zamanının bir bölümü (30 saniye için 30 da 1’i) kullanılır, bu nedenle kodun değişmesi ne kadar uzun sürer ise hassaslıkta o kadar azalmaktadır. Zaman kullanımı sonucunda ortaya çıkan öteki problem ise sunucularda bulunan diğer uygulamalardır. Eğer sunucuda bulunan diğer uygulamalar zaman verisini dışarıya sızdırıyor ya da zaman verisi herkesin erişebileceği ortak bir kaynak üzerinden kullanılıyor ise bir sonraki kodu tahmin etmek daha da kolay hale gelir. Yine de saldırganların gizli değeri bilmeleri gerekmektedir ama sistemi koruyan iki değerden (gizli veri ve zaman) birisi atlatılmış olur. Google Authenticator uygulamasını üç adımda daha kolay inceleyebiliriz;

 

1.) Yeni hesap ekleme

 Google Authenticator uygulamasına yeni bir hesap eklerken ortaya çıkan gizli anahtar eşleştirmesi problemini, kamera ile çekilen bir QR kod ya da el ile girilen gizlilik verisi ile çözmüştür. Bu sayede kullanıcı gizlilik verisini kendisi eşleştirir ve ekleme sırasında sistem (sunucu), kullanıcı (uygulama) ile bir bağlantı yapmaz. Bir bağlantının olmaması ve sadece gizlilik verisinin el ile eşleştirilmesi nedeniyle zaman, uygulamanın bulunduğu sistem (telefon) tarafından sağlanılır. Bu nedenle uygulamanın bulunduğu sistemin zamanının doğru olması gerekmektedir aksi taktirde eşleşme problemleri ortaya çıkmaktadır.

 

2.) Var olan hesabı kullanma

Google Auth kullanan bir servise giriş sırasında sizden talep edilen veriyi uygulama tarafından oluşturup, paylaşmanız gerekmektedir. Bu veri HOTP için, o anki sayaç değeri (ör, 10) ile sonraki ileri bakış kadar sayaç değeri (ör, 20 bu da counter 10-30 arası demek) kullanılarak hesaplanan HOTP değerine karşı kontrol edilir ve eşleşme bulunan değere göre sayaçlar eşitlenir. Google, kullandığı HOTP ileri bakış değerini açıklamamaktadır ama yakın bir rakibi olan Yubikey firmasının dökümanlarında bu değerin 50-80 arasında olmasının ideal olduğu ve 100’ü geçmemesi gerektiğinden bahsedilir. Zaman bazlı (TOTP) yönteminde ise iki taraf zamana bağlı kod üretir ve uygulamanın ürettiği kod kullanıcı tarafından sisteme girilir. Sistemdeki kod eşleşmiyor ise zaman problemi ortaya çıkar ve iki sistemde de zamanın eşitlenmesi/güncellenmesi gerekmektedir.

 

3.) Hesap silme/taşıma

2FA kullanan sistemlerde hesap işlemleri self servis ve yönetici destekli olmak üzere iki şekilde yapılmaktadır. Self servis yönteminde kullanıcı, sunucuda bulunan hesap ile ilgili işlemleri (sayaç değeri değiştirme/eşitleme, gizlilik verisinin değişimi ve hesap silme) kendisi yapabilmektedir. Bu değerlerden bazılarının değişimini yetkisiz/az yetkili kullanıcılara bırakmak güvenlik problemleri doğurabilmektedir ve bu nedenle bu değerlerin sadece belirli bir kısmı değiştirilebilmekte veya görüntülenebilmektedir. Google Auth. kullanan servislerde hesabın silinmesi için öncelikle 2FA kullanılan servise giriş yapılması ve ayarlar kısmından 2FA’nın kaldırılması, sonra Google Auth. uygulamasından silinmesi gerekmektedir. Eğer ilk önce Google Auth. uygulamasından silinme işlemi gerçekleştirilirse, servise giriş yapılamayabilir ve sistem/servis yöneticisine başvuru yapılması gerekmektedir.

Hesap taşımak için ise paylaşılan gizlilik verisinin yeni Google Auth. uygulamasına geçirilmesi gerekmektedir. Bu da eski Google Auth. bulunan her hesap için tekrardan giriş yapılıp, ayarlardan değişim bölümüne gidilmesi ve çıkan QR kodunun yeni Google Auth. hesabı ile taranması ya da çıkan kodun yeni hesaba el ile girilmesi demektir. Bu durum ise her hesabı tekrardan ziyaret etmenin ve taşıma işleminin el ile yapılması gerekliliğinin getirdiği zorluklar nedeniyle uzun sürmekte ve zaman harcamanıza neden olmaktadır. Bunu 2013’te yaşanan güncelleme krizi ile birleştirince, uygulamanın kullanıcılara sunduğu deneyim oldukça düşük kalmaktadır. 2013 yılında yapılan bir Google Auth. güncellemesi sonucunda güncellemeyi yükleyen bütün kullanıcıların 2FA anahtarları otomatik olarak silinmiştir bu da çoğu kullanıcının, yeniden kurulumun ne kadar problem yaratabileceğinin farkına varmasını sağlamış ve alternatif aramasına neden olmuştur. 2013 krizini takiben çıkan sürede, silinen uygulamanın anahtarları tamamen yok etmediği (https://github.com/google/google-authenticator/issues/632) ortaya çıkmıştır ve benzeri problemlerin ortaya çıkması sonucunda uygulamanın kullanımı gittikçe azalmıştır.

 

Kırmızı köşe, Authy,

Evet, kullanıcıların eşleştirme problemine karşı doğan ve bu probleme daha kolay bir çözüm sunan Authy uygulaması, bir çok büyük servis ile ortak çalışmakta ve aynı zamanda Google Auth. anahtarlarını da desteklemektedir. Authy, eklenilen hesapların bulut üzerinden bütün cihazlar ile senkronize olmasını sağlamaktadır ve bu sayede hesapların aktarımı daha kolay hâle gelmektedir. Web sitesinde, Twitter mesajları baz alınarak belirtilen geçiş süreci itibariyle Google Auth. ve Authy farkları listelenmektedir. Bu liste, hatalı bir makaleden alınma “Google Auth. aynı anda sadece bir cihazda kullanılabilmektedir, ikinci bir cihaz kullanılmak istendiğinde Google otomatik olarak ilk cihazı silmektedir” bölümü ve çoklu parola desteğinin açıklamak için yönlendirdiği twillio destek linkinin artık var olmaması dışında Authy’nin avantajlarını çok güzel bir biçimde aktarmaktadır. 

Bu avantajlar ise Google Authenticator’ın eksileri göz önüne alındığında belirgin olmaktadır:

  • Google Authenticatiro uygulamasının sadece mobil cihazlarda bulunması ve bilgisayarlar ile tarayıcı eklentileri olarak kullanılamaması.
  • Hesap aktarımı yaparken şifreli yedekleme yapamaması ve bu nedenle aktarım sürecinin zorluğu.
  •  Parola korumasına sahip olmaması ve sadece cihaz güvenliğine güvenmesi,
  • Uzun süredir güncellenmemesi ve bilinen problemlerinin olması,
  • Kullanımının gün geçtikçe azalması nedeniyle destekleyen servislerin azalması

Yazımızı Authy uygulamasının güvenliğinin incelenmesi ile bitirmek isteriz.

İlk nokta, Authy uygulamasının getirdiği çoklu parolalar. Google Auth. uygulamasına giriş esnasında parola bulunmamaktadır ve cihazın kilit ekranını geçebilen bütün saldırganlar Google Auth. uygulamasına erişebilmektedir. Cihaz kilit ekranının geçilebildiğini gösteren zafiyetlerin gün geçtikçe daha fazla ortaya çıkması nedeniyle cihaza duyulan güven kullanıcılar tarafından sorgulanmaktadır. Bunu, cihazı günlük kullanımında hızlı kullanabilmek amacıyla daha kolay parolalar ile koruyan kullanıcıların da izlemesi nedeniyle cihaz güvenliğine dayanan güvenlik çözümleri sanılanın aksine gerektiği kadar güvenli olmamaktadır. Authy bu duruma özgü olarak uygulamayı ve hesapları üç adet parola ile koruma altına almıştır. Bu parolalardan ilki olan yedekleme (backup) parolası bulut sisteminde kullanılan yedekleri korumaktadır. Bu sayede Authy nin bulut sistemlerine karşı bir saldırı gerçekleşmiş olsa dahi saldırganlar sizin 2FA bilgilerinizi ele geçirememektedir. 

Bir diğer güvenlik önlemi ise PIN korumasıdır. Bu önleme parola demek hatalıdır ama parola, PIN, şifre kavramlarının kargaşasına bu yazıda değinilmemektedir, sadece bu hatanın bilinmesi yeterlidir. PIN koruması uygulamaya giriş esnasında kullanıcıdan talep edilen 4 haneli kod şeklinde kullanılmaktadır ve uygulamaya yapılacak izinsiz girişleri engellemektedir. Bu güvenlik önlemi cihazı ele geçirmiş (ve cihazın yedeğine sahip) saldırganlar için bir engel teşkil etmemektedir. Son güvenlik önlemi olan Ana parola (Master Password) ise sadece Authy’nin bilgisayar versiyonunda bulunmaktadır. Bu önlem bilgisayarın kullanılmadığı zaman uygulamanın parola ile korunmasını sağlar. Bu parola PIN korumasının daha uzun ve bilgisayar uygulaması için tasarlanmış türüdür diyebiliriz.

 

Authy’nin kullandığı yedekleme parolası için PBKDF2 fonksiyonunu kullanmaktadır. Bu fonksiyon sizin girdiğiniz parolayı giriş olarak alıp, daha uzun ve rassallığı daha yüksek bir çıktı üretmektedir. Bu sayede girilen düşük güvenlikli parolalar bile daha güvenli hale gelmektedir. Bunun yanında Authy parolaları tuzlamakta (parolalara bir değer eklemekte) ve 1000 defa özet almaktadır (HASH). Bu değerin mobil cihazların işlem kapasitesinin artması ile doğru orantılı olarak artacağını dile getiren Authy, tuz (salt) değerinin güvenli ve rastgele bir veriden oluştuğunu söylemektedir. Sonrasında bütün 2FA anahtarları PBKDF2 fonksiyonunun çıktısını kullanarak AES-256, CBC modu ile şifrelenmektedir. Bu modda kullanılan IV ise her hesaba göre değişmektedir. Eğer herhangi bir 2FA anahtarı 128 bitten daha küçük ise PKCS#5 ile doldurulmaktadır. Bu işlemlerin sonucunda sadece şifrelenmiş sonuc, tuz ve IV değeri sunucuya gönderilmektedir. Şifreleme ve şifre çözümü için gereken anahtar sunucuda bulunmamaktadır ve bu sayede sunucuda tutulan verinin güvenliği sağlanmaktadır. Burada araştırma yapmadan önce göze ilk çarpan ve problem yaratabilecek noktalar ise PKCS#5 fonskiyonu ile tuz ve IV üretimidir. PKCS#5 dendiğinde aklımıza ilk gelen saldırı olan Padding Oracle ile hesap verilerinden üretilen IV değerinin güvenliği (bu işlemleri yapan fonksiyonlar) zincirdeki en zayıf halkayı oluşturmaktadır. Tuz üretiminin güvenliği ise paylaşılan link sayesinde güvenlik önlemlerinin alındığına dair bir güven sunmaktadır ama yine de zincirin en zayıf ikinci halkasını tuz üretimi oluşturmaktadır. 

 

Güven problemi,

Authy hem 2FA hizmeti sağlamakta, hem de 2FA hizmeti sağlayan diğer uygulamaları güvenli bir biçimde desteklemektedir. Evet, yanlış duymadınız, kendi 2FA hizmetinin desteği güvenlik problemine sahiptir ama bu problem diğer desteklenen sistemlerde görülmemektedir. 

Nasıl mı? Authy 2FA hizmeti kullanan sistemler size bir kod veya QR kodu vermek yerine sizden telefon numaranızı istemektedir. Bu numarayı hem üye olduğunuz web servisi hem de Authy bildiği için ikisi otomatik olarak eşleşmektedir. Bu şekilde eşleşen hesapların yarattığı 2FA kodları ise RFC4226 / Google Auth. 6 haneli kodlarına nazaran 7 haneli olarak üretilmektedir. Authy’nin 7 haneli 2FA kodları ise bulutta daha önce bahsedildiği gibi güvenli bir biçimde depolanmamaktadır. Bulut depolaması şifreli olmak yerine Authy hesabınıza bağlanmaktadır. Bu da yeni bir cihaza Authy kurduğunuz ve doğrulama yaptığınız anda Authy ile eklenen bütün anahtarlara sahipsiniz demektir. Yani hesabınıza erişen bütün saldırganlar bulutta yedeklemek için kullandığınız parolayı kullanmadan, Authy 7 haneli 2FA kodlarınızı görebilmekte ve bu kodları oluşturmak için kullanılan değerlere erişebilmektedir. Authy’nin kendi 2FA hizmeti bulut parolalarını kullanmamakta ve sadece uygulamanın/hesabın güvenliğini temel almaktadır. Authy hesabın güvenliğini nasıl sağlamaktadır, diye soracak olursanız cevabımız; SMS. Evet yeni bir Authy uygulaması kurulduğunda eski parolaların aktarımı için eski uygulamadan doğrulama ya da SMS doğrulaması gerektirmektedir. SMS doğrulaması konusunda numara gizleme/değiştirme (spoofing) yapılarak farklı numaralardan doğrulama gönderilebileceğini aklımızda bulundurarak bu yaklaşımın, bulut yedekleri konusunda daha problemli olduğunu söyleyebiliriz. 

Yani kısacası Authy hesap aktarımı sonrasında Google Auth. anahtarınız şifreli iken Authy 2FA ile oluşturulmuş anahtarlarınız şifresiz olmaktadır. Bu nedenle büyük kripto para tartışma siteleri Authy yerine tekrar Google Auth. uygulamasına geçiş yapmıştır. Size önerimiz ise eğer taşıma konusunda bir probleminiz yok ise Google Auth kullanmanız, diğer durumlarda ise yine Google Auth kullanıp, Google Auth anahtarınızı Authy üzerinden bulut şifreleme ile saklamanız (Authy uygulamasını 2FA için değil, 2FA anahtarınızın çok cihazda desteğini sağlamak için kullanmanız) olacaktır.

 

Kaynaklar: