Sha256'dan Daha Güvenli Bir Hash Algoritması

[yusufyilmazfr]

Uygulama içerisinde örnek bir hash algoritması olsun ve süreç devam edilsin diye Sha256 kullanıldı.

Sha256'dan daha güvenli ya da çözülmesi daha uzun süren başka bir algoritma da kullanılabilir. Brute-force ve diğer atakların önüne geçmek için. Önerileri bekliyoruz. 👇

[oguzkurtcuoglu]

Öncelikle aspnetcore identity neden kullanmadık ve neden kendimiz auth işlemlerini yaptık? Belirli bir sebebi mi var bilmediğim için soruyorum.
Gördüğüm kadarı ile register esnasında, kullanıcının şifresi 1 kez sha256 ile şifrelenip öyle saklanıyor. Aspnetcore Identity içerisinde 1000 iterasyon gerçekleşir ve direkt plain text hashlenmez. Salt ekleme gibi başka bir çok operasyonda yapılıyor. Bu tarz özellikle security ile ilgili işlemlerin tüm usecase'lerini kendimiz implemente etmemiz çok zor. Ayrıca ekstra bir sebep yok ise bu daha da zaman alıcı olacaktır. Öncelikle aspnetcore identity konusunu netleştirelim derim :)

Sorudaki Sha256'dan daha güvenli ve çözülmesi uzun konusuna gelirsek, Çözülme durumu tabi bildiğiniz üzere mümkün değil ama rainbow table'larda özellikle basit şifrelerin encrypt halleri bulunabiliyor. Zaten bu yüzden direkt plain text alınıp tek sefer sha256 hale getirmek yeterli değil. https://github.com/aspnet/Identity/blob/master/src/Core/PasswordHasher.cs buradan bir password hash'in nasıl yapıldığına bakabilirsin. V3'e bakarsan daha iyi olacaktır.

[yusufyilmazfr]

ASPNET Core Identity kullanmamak için özel bir sebebimiz yok açıkçası. Kaynak kodların sade, bir o kadar da başka şeylere ihtiyacı olmamasını istedik. JWT + Hash temel olarak işimizi görür diye düşündük. Yetersiz geldiği durumlarda tabii değerlendirilebilir.

Hash algoritması kısmında ise proje başlangıcında "Hangi hash algoritmasını kullanalım?" sorusuna zaman kaybetmemek için SHA256 ile başladık. O işlemler zaten soyutlandı, implementasyon detaylarına çok odaklanmadık. Şimdi iyi bir tartışma konusu olabilir diye düşündük. Salt key ve yüksek iterasyon sayısı ile de olabilir, hangisi daha uygun ise.

Daha güvenli ya da çözülmesi uzun sürecek kısmını detaylandırmak gerekirse de, evet hash algoritmaları geri dönülebilir değil. Brute force atakları gibi yöntemler ile karşılaştırılarak bulunabilir. Buradaki algoritmanın çalışma hızına değinmek istemiştim, bazı algoritmalar yavaş çalıştığından dolayı bu saldırılar çok uzun sürmektedir. Bknz: Bcrypt | StackOverflow

[umutluoglu]

Selamlar, Yusuf'un da dediği gibi projeye başlarken her şeyi basit tutalım, soyutlanabilir olsun, sırası geldikçe buraları iyileştiririz dedik. Amaç mükemmel bir proje ortaya çıkarmak değil de, hızlı ve iş görür bir proje çıkarmaktı. Identity'i sanırım ekstra tablolar vs. getirdiği ve ayrı bir implementasyon yapma gerekliğinden dolayı şimdilik kullanmayalım demiştik. Eğer Identity kullanmadan, daha basit implemantasyonlarla bu işi çözebiliyorsak öyle yapalım. Hatta şunu bile düşünebiliriz, projeye sadece Google, Facebook veya GitHub ile login olunabilir, böylece güvenlik kısmındaki yükü üzerimizden atmış oluruz :) Yusuf Yılmaz ***@***.***>, 22 Haz 2021 Sal, 08:01 tarihinde şunu yazdı:

…

ASPNET Core Identity kullanmamak için özel bir sebebimiz yok açıkçası. Kaynak kodların sade, bir o kadar da başka şeylere ihtiyacı olmamasını istedik. JWT + Hash temel olarak işimizi görür diye düşündük. Yetersiz geldiği durumlarda tabii değerlendirilebilir. Hash algoritması kısmında ise proje başlangıcında "Hangi hash algoritmasını kullanalım?" sorusuna zaman kaybetmemek için SHA256 ile başladık. O işlemler zaten soyutlandı, implementasyon detaylarına çok odaklanmadık. Şimdi iyi bir tartışma konusu olabilir diye düşündük. Salt key ve yüksek iterasyon sayısı ile de olabilir, hangisi daha uygun ise. Daha güvenli ya da çözülmesi uzun sürecek kısmını detaylandırmak gerekirse de, evet hash algoritmaları geri dönülebilir değil. Brute force atakları gibi yöntemler ile karşılaştırılarak bulunabilir. Buradaki algoritmanın çalışma hızına değinmek istemiştim, bazı algoritmalar yavaş çalıştığından dolayı bu saldırılar çok uzun sürmektedir. Bknz: Bcrypt <https://tr.wikipedia.org/wiki/Bcrypt> | StackOverflow <https://stackoverflow.com/a/15763253> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITWF4SFRMPVMYW6BOPPVT3TUAKMNANCNFSM467XGRRA> .

[oguzkurtcuoglu]

Şu an yapılmış değiştirelim diye demiyorum öncelikle :) Yalnız auth işlemlerinde sadece login/register olayları değil bildiğiniz üzere password Reset, email Verification gibi başka handle edilmesi gereken olaylarda var. Bu yüzden sonraki projelerde bunları da göz önünde bulundurarak var olan sistemleri kullanırsak daha az uğraştığımız ve daha iyi/güvenli olan bir yapımız olacaktır. Tabi abstraction uygulamak çok mantıklı auth sistemini tamamen kendimizin yazması gerektiği durumlarda olabilir bu yanlıştır demiyorum. Sadece yapılanı anlamak ve bildiğim kadarı ile fikir vermek için yazdım :).

@yusufyilmazfr aslında şifrelemede bir çok algoritmayı kombine ederek süreler tabiki uzatılabilir ama şöyle bir durum var bu sadece saldıranı değil bizim kendi sistemimizide yoracaktır. Günümüzde özellikle Cloud çözümlerde cpu işlem süreleri çok önemli bildiğiniz üzere. Biz bu algoritmayı çok çok zorlaştırıp uzun sürmesini sağlayabilir miyiz evet ama bu bizim sunucu maliyetimizide ciddi oranda etkileyecektir özellikle saldırı altında olduğumuz durumlarda. Şöyle düşünelim atıyorum login ekranında aldığımız şifreyi hashlememiz 2 saniye sürsün. Sonrasında bu hash'i db de olan hash ile karşılaştıracağız malum. Bir DDOS saldırısında belki binlerce client bu logine saldıracak. Bu durumda Cloud provider'lara iyi paralar ödememiz gerekecektir :) @umutluoglu hocam yanlış/eksik varsa sizin düşüncenizi de beklerim..

@yusufyilmazfr https://www.youtube.com/watch?v=gdI71QhJ1H0 buradan Gökhan Şengün'ün konumuz ile ilgili anlatımını izlemeni hatta Youtube'a Gökhan Şengün yazıp yaptığı tüm sunumların videolarını izlemeni tavsiye ederim. @umutluoglu hocam tanıyacaktır Gökhan çok güzel anlatımlar yapmakta.

[yusufyilmazfr]

@oguzkurtcuoglu öncelikle güzel önerileriniz için teşekkür ediyorum, Gökhan Şengün'ü severek takip ediyorum ve o videosunu da izlemekten hoşnut olurum. :)

Şunu da söylemem gerekiyor ki söylediklerinizde sonuna kadar haklısınız burada karşı duracağım bir şey de yok, benim açıklamalarımda bu fikri yapmamızdaki düşüncelerimizi dile getirdim. :)

[umutluoglu]

Beyler en doğrusu hangi yöntemse o yöntemi tercih edelim. Diğer yandan şifre işlemi talebi sisteme günlük 200-300 adetten fazla gelmeyecektir, belki sistem ilk açıldığı 2-3 gün günlük 2000-3000 request gelir. Saldırı durumunda bu tip floodingleri engellemek için limiter middleware'i yazabiliriz. Saldırı geldikten sonra şifreli-şifresiz işlem ayrımı olmaz zaten. Böyle bir kaygımız olacaksa her türlü flooding'i engelleyecek bir middleware yapmalıyız. Misal aynı makineden 30 saniye içinde aynı endpoint max 3 kez çağrılabilir, 60 saniyede 6 req. gelirse o makineyi 5 dk.lığına blokla gibi. Pagination yapan api'larda bu rakamlar esnetilir. Diğer yandan cloudflare'de bu tip floodları engelleyen bir ayar vardı diye biliyorum. Ben bir önceki maildeki önerimi yineleyeceğim; bence sistemde hiç password tutmayalım, sadece github ve google login'e izin verelim. Zaten profil doldurmaları için github gerekecek hemen her kullanıcı için. Bunu neden düşünmüyoruz? Yusuf Yılmaz ***@***.***>, 27 Haz 2021 Paz, 13:01 tarihinde şunu yazdı:

…

@oguzkurtcuoglu <https://github.com/oguzkurtcuoglu> öncelikle güzel önerileriniz için teşekkür ediyorum, Gökhan Şengün'ü severek takip ediyorum ve o videosunu da izlemekten hoşnut olurum. :) Şunu da söylemem gerekiyor ki söylediklerinizde sonuna kadar haklısınız burada karşı duracağım bir şey de yok, benim açıklamalarımda bu fikri yapmamızdaki düşüncelerimizi dile getirdim. :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITWF4STUF6NIGHX2ITHUHDTU3ZF5ANCNFSM467XGRRA> .

[oguzkurtcuoglu]

Uğur hocam dediğiniz bencede çok mantıklı. Sisteme github ve google login koysak yeterli olacak bencede. Projenin bir dökümanı falan var mı ? Projenin özellikleri neler bilmiyorum hiç 😊 Birde development db online yapsak mı yada bana db backup gönderebilir misiniz? Yusuf rica ederim 😊 Üzerine epey konuşulabilecek bir konu bu.

…

Sent from my iPhone

On 27 Jun 2021, at 15:00, Ugur Umutluoglu ***@***.***> wrote:  Beyler en doğrusu hangi yöntemse o yöntemi tercih edelim. Diğer yandan şifre işlemi talebi sisteme günlük 200-300 adetten fazla gelmeyecektir, belki sistem ilk açıldığı 2-3 gün günlük 2000-3000 request gelir. Saldırı durumunda bu tip floodingleri engellemek için limiter middleware'i yazabiliriz. Saldırı geldikten sonra şifreli-şifresiz işlem ayrımı olmaz zaten. Böyle bir kaygımız olacaksa her türlü flooding'i engelleyecek bir middleware yapmalıyız. Misal aynı makineden 30 saniye içinde aynı endpoint max 3 kez çağrılabilir, 60 saniyede 6 req. gelirse o makineyi 5 dk.lığına blokla gibi. Pagination yapan api'larda bu rakamlar esnetilir. Diğer yandan cloudflare'de bu tip floodları engelleyen bir ayar vardı diye biliyorum. Ben bir önceki maildeki önerimi yineleyeceğim; bence sistemde hiç password tutmayalım, sadece github ve google login'e izin verelim. Zaten profil doldurmaları için github gerekecek hemen her kullanıcı için. Bunu neden düşünmüyoruz? Yusuf Yılmaz ***@***.***>, 27 Haz 2021 Paz, 13:01 tarihinde şunu yazdı: > @oguzkurtcuoglu <https://github.com/oguzkurtcuoglu> öncelikle güzel > önerileriniz için teşekkür ediyorum, Gökhan Şengün'ü severek takip ediyorum > ve o videosunu da izlemekten hoşnut olurum. :) > > Şunu da söylemem gerekiyor ki söylediklerinizde sonuna kadar haklısınız > burada karşı duracağım bir şey de yok, benim açıklamalarımda bu fikri > yapmamızdaki düşüncelerimizi dile getirdim. :) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#15 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AITWF4STUF6NIGHX2ITHUHDTU3ZF5ANCNFSM467XGRRA> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[umutluoglu]

O halde issue list'e login sisteminin sadece Github ve Google hesaplarıyla login olunacak şekilde düzenlenmesi, mentor db tarafında password tutulmasına gerek olmayacağı şekilde yapının yeniden ele alınması diye bir madde ekleyelim. Database'i code first'e çevirecekti Yusuf, hatta çevirdi sanırım. Ben yine de db create scriptlerini ekte iletiyorum. Backup dosyası iletmiyorum, genelde sürüm uyumsuzluğu çıkıyor çünkü. Oguz KURTCUOGLU ***@***.***>, 27 Haz 2021 Paz, 15:24 tarihinde şunu yazdı:

…

Uğur hocam dediğiniz bencede çok mantıklı. Sisteme github ve google login koysak yeterli olacak bencede. Projenin bir dökümanı falan var mı ? Projenin özellikleri neler bilmiyorum hiç 😊 Birde development db online yapsak mı yada bana db backup gönderebilir misiniz? Yusuf rica ederim 😊 Üzerine epey konuşulabilecek bir konu bu. Sent from my iPhone > On 27 Jun 2021, at 15:00, Ugur Umutluoglu ***@***.***> wrote: > >  > Beyler en doğrusu hangi yöntemse o yöntemi tercih edelim. Diğer yandan > şifre işlemi talebi sisteme günlük 200-300 adetten fazla gelmeyecektir, > belki sistem ilk açıldığı 2-3 gün günlük 2000-3000 request gelir. Saldırı > durumunda bu tip floodingleri engellemek için limiter > middleware'i yazabiliriz. Saldırı geldikten sonra şifreli-şifresiz işlem > ayrımı olmaz zaten. Böyle bir kaygımız olacaksa her türlü > flooding'i engelleyecek bir middleware yapmalıyız. Misal aynı makineden 30 > saniye içinde aynı endpoint max 3 kez çağrılabilir, 60 saniyede 6 req. > gelirse o makineyi 5 dk.lığına blokla gibi. Pagination yapan api'larda bu > rakamlar esnetilir. Diğer yandan cloudflare'de bu tip floodları engelleyen > bir ayar vardı diye biliyorum. > > Ben bir önceki maildeki önerimi yineleyeceğim; bence sistemde hiç password > tutmayalım, sadece github ve google login'e izin verelim. Zaten profil > doldurmaları için github gerekecek hemen her kullanıcı için. Bunu neden > düşünmüyoruz? > > > Yusuf Yılmaz ***@***.***>, 27 Haz 2021 Paz, 13:01 tarihinde > şunu yazdı: > > > @oguzkurtcuoglu <https://github.com/oguzkurtcuoglu> öncelikle güzel > > önerileriniz için teşekkür ediyorum, Gökhan Şengün'ü severek takip ediyorum > > ve o videosunu da izlemekten hoşnut olurum. :) > > > > Şunu da söylemem gerekiyor ki söylediklerinizde sonuna kadar haklısınız > > burada karşı duracağım bir şey de yok, benim açıklamalarımda bu fikri > > yapmamızdaki düşüncelerimizi dile getirdim. :) > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > < #15 (comment) >, > > or unsubscribe > > < https://github.com/notifications/unsubscribe-auth/AITWF4STUF6NIGHX2ITHUHDTU3ZF5ANCNFSM467XGRRA > > > . > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITWF4XJHUPP7Y5XTGTRJNDTU4KAHANCNFSM467XGRRA> .

[yusufyilmazfr]

Migration işlemleri için PR atmıştım şu an da açık, burada kullanımı var. database-migration

[umutluoglu]

Sen PR'ları merge edemiyor musun Yusuf? Ben artık kod review yapmıyorum, zira koptum işin gidişinden, baksam da sağlıklı olmaz. Top artık ikinizde, aranızda paslaşıp PR'ları merge edin beni beklemeyin :) Yusuf Yılmaz ***@***.***>, 27 Haz 2021 Paz, 15:53 tarihinde şunu yazdı:

…

Migration işlemleri için PR atmıştım şu an da açık, burada kullanımı var. database-migration <https://github.com/devnotcom/devnot-mentor-back-end/tree/migration-usages#database-migration> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AITWF4VOGLFTJIF2EKQW4Y3TU4NKXANCNFSM467XGRRA> .