Bir e-pin sitesine üye olan kullanıcı, aslında cüzdanındaki bakiyeyi, sipariş geçmişini ve çoğu zaman kayıtlı kart bilgilerini de o hesaba emanet eder. Sorulması gereken soru şu: o hesabın şifresi veritabanınızda nasıl duruyor? Düz metin mi, zayıf bir hash mi, yoksa modern bir şifreleme algoritması mı? Bu yazıda e-pin ve dijital ürün satış scriptlerinde şifreleme nasıl çalışır, hangi yöntemler güvenli sayılır ve Pinova bu konuyu hangi katmanlarda ele alır, sırayla anlatıyoruz.
Bir Şifre Sızıntısı Aslında Ne Kaybettirir?
E-pin sitelerinin çoğu, kullanıcıyı yalnızca bir e-posta ve şifre çiftinden ibaret sanma hatasına düşer. Oysa o hesabın arkasında genelde bir cüzdan bakiyesi, geçmiş sipariş ve fatura bilgisi, bazen kayıtlı ödeme yöntemi vardır. Şifre çözüldüğünde saldırgan sadece "içeri girmiş" olmaz; aynı zamanda:
- Cüzdandaki bakiyeyi harcayabilir veya transfer edebilir
- Sipariş geçmişinden hangi oyunları oynadığını, hangi platformları kullandığını öğrenip hedefli dolandırıcılık kurgulayabilir
- Aynı şifreyi başka sitelerde de deneyerek (credential stuffing) zincirleme hesap ele geçirme yapabilir
- Bayi hesabıysa, komisyon bakiyesini ve alt bayi ağını tehlikeye atabilir
Yani şifreleme, süslü bir teknik detay değil; işin ekonomik omurgasıdır. Bir e-pin scripti seçerken sorulacak en pratik sorulardan biri, "şifreler veritabanında nasıl saklanıyor" olmalı.
Düz Metin Şifreleme Neden Hâlâ Bazı Scriptlerde Karşımıza Çıkıyor?
İnanması güç ama küçük ölçekli veya amatörce yazılmış bazı e-ticaret ve e-pin scriptlerinde şifreler hâlâ veritabanına olduğu gibi, düz metin (plaintext) olarak yazılır. Nedeni genelde tembellik değil, "şifremi unutan kullanıcıya kolayca gönderirim" mantığıdır — ki bu da ayrı bir güvenlik açığıdır, çünkü güvenli bir sistem şifreyi asla e-postayla geri gönderemez, sadece sıfırlama linki gönderebilir.
Düz metin saklamanın riski basit: veritabanına herhangi bir yolla erişim sağlayan biri (SQL injection, yedek dosya sızıntısı, yanlış yapılandırılmış phpMyAdmin) anında tüm kullanıcı şifrelerine sahip olur. Ekstra bir kırma, deşifre etme adımına gerek yoktur. Bu yüzden düz metin saklama, sektörde "asla yapılmaması gereken" listesinin en başında yer alır.
Hashing ile Şifreleme Arasındaki Fark Neden Kafa Karıştırıyor?
Burada sık yapılan bir terim hatası var: "şifreleme" (encryption) ve "özetleme" (hashing) aynı şey değildir. Şifreleme geri döndürülebilir — doğru anahtarla şifre çözülüp orijinal veri elde edilebilir. Hashing ise tek yönlüdür; bir şifre hash'lendiğinde, o hash'ten orijinal şifreye geri dönmek matematiksel olarak (pratikte) imkânsızdır.
Kullanıcı şifreleri için doğru yaklaşım hashing'dir, çünkü sitenin sahibinin bile kullanıcının gerçek şifresini bilmesine gerek yoktur — sadece girilen şifrenin hash'i, saklanan hash'le eşleşiyor mu diye kontrol edilir. Kredi kartı numarası gibi geri çözülmesi gereken veriler için ise gerçek şifreleme (AES gibi) kullanılır. İki kavramı karıştıran bir script, yanlış yerde yanlış yöntemi uygulama riskiyle karşı karşıyadır.
MD5'ten Argon2'ye: Hangi Algoritma Gerçekten Güvenli?
Hashing algoritmaları eşit yaratılmamıştır. MD5 ve SHA-1 gibi eski algoritmalar hızlı çalışacak şekilde tasarlandığı için, tam da bu yüzden şifre saklamada kötü bir seçimdir — hızlı hash, saldırganın saniyede milyarlarca kombinasyon deneyebilmesi (brute force) demektir. Modern kullanıcı şifreleri için tasarlanan algoritmalar ise bilinçli olarak yavaş ve kaynak yoğun çalışır:
- bcrypt — yıllardır endüstri standardı, "salting" (tuzlama) işlemini otomatik yapar, ayarlanabilir maliyet faktörü sunar
- Argon2 — Password Hashing Competition'ı kazanan, hem CPU hem bellek yoğun çalışarak GPU tabanlı saldırılara karşı daha dirençli güncel algoritma
- PBKDF2 — özellikle uyumluluk gerektiren (FIPS gibi) ortamlarda tercih edilen, tekrar sayısı artırılabilen bir yöntem
Tuzlama (salting) burada kritik bir ek katman: her kullanıcı için benzersiz rastgele bir değer üretilip şifreyle birlikte hash'lenir. Bu sayede iki kullanıcı aynı şifreyi kullansa bile veritabanındaki hash'leri tamamen farklı görünür, hazır "rainbow table" saldırıları işe yaramaz hale gelir.
| Şifreleme Kriteri | Manuel / Elle | Pinova ile |
|---|---|---|
| Şifre saklama yöntemi | Genelde MD5 veya belirsiz, kontrol edilmemiş | bcrypt tabanlı, tekli yönlü hash |
| Tuzlama (salting) | Elle eklenmezse çoğu zaman yok | Her kayıt için otomatik benzersiz tuz |
| Sızıntı sonrası risk | Hash kırılırsa şifreler doğrudan açığa çıkar | Maliyetli algoritma, kitlesel kırma pratik değil |
| Şifre sıfırlama akışı | Genelde şifreyi mail ile geri gönderme riski | Süreli, tek kullanımlık sıfırlama token'ı |
| Oturum/token güvenliği | Elle yazılmış, test edilmemiş session mantığı | Hazır, denenmiş oturum ve yetki katmanı |
Pinova Kullanıcı Verilerini Hangi Katmanlarda Korur?
Bir e-pin scriptinde güvenlik tek bir noktada değil, birkaç katmanda birden sağlanmalı. Pinova bu yaklaşımı benimser:
- Şifre saklama: Kullanıcı ve bayi şifreleri, veritabanında asla düz metin olarak tutulmaz; tek yönlü, tuzlu hash yöntemiyle saklanır
- Cüzdan işlemleri: Bakiye hareketleri loglanır, tutarsız veya olağan dışı işlemler takip edilebilir şekilde kayıt altına alınır
- Ödeme entegrasyonları: Kart bilgileri sitenin kendi veritabanında tutulmaz; PayTR ve Shopier gibi PCI-DSS uyumlu ödeme sağlayıcıları üzerinden işlenir
- Admin ve bayi paneli erişimi: Yetki seviyeleri ayrıştırılmıştır; bir bayi başka bir bayinin verisine veya admin ayarlarına erişemez
- Oturum yönetimi: Uzun süreli, tahmin edilebilir oturum token'ları yerine güvenli oturum kontrolü uygulanır
Bu, "kur ve unut" değil, kendi sunucunuza kurduğunuzda dahi bu temel güvenlik mimarisini elinizde bulacağınız anlamına gelir — üzerine ekstra bir güvenlik katmanı (örneğin iki adımlı doğrulama) eklemek istediğinizde de zemin hazırdır.
Hazır bir script satın alsanız bile, veritabanı yapısını hızlıca kontrol edin: kullanıcılar tablosunda şifre alanı 32 veya 40 karakter sabit uzunluktaysa (MD5/SHA-1 belirtisi) ve tuz sütunu yoksa, o script muhtemelen eski ve zayıf bir yöntem kullanıyordur. bcrypt hash'leri genelde "$2y$" ile başlar ve değişken uzunluktadır — bu, doğru yolda olduğunuzun basit bir işaretidir.
Kullanıcı Şifresi Yanında Hangi Alışkanlıklar Sistemi Daha Güvenli Yapar?
Güçlü bir şifreleme algoritması tek başına yeterli değildir; onu çevreleyen alışkanlıklar da en az onun kadar önemlidir:
- Admin paneline giriş için tahmin edilemez URL veya ek erişim anahtarı kullanmak
- Başarısız giriş denemelerini sınırlamak (brute force / kaba kuvvet saldırılarına karşı)
- Şifre sıfırlama linklerini kısa süreli ve tek kullanımlık yapmak
- Veritabanı yedeklerini herkese açık bir klasörde bırakmamak — bu, ironik biçimde en sık rastlanan sızıntı nedenlerinden biridir
- SSL/HTTPS zorunlu kılmak, böylece şifreler ağ üzerinde bile açık gitmez
Bir e-pin scripti değerlendirirken sadece "hash algoritması ne" diye sormak yetmez; bu alışkanlıkların script içinde varsayılan olarak gelip gelmediğine de bakmak gerekir. Çünkü çoğu satıcı, güvenliği "isteğe bağlı ek modül" olarak sunar; oysa temel olması gereken bir şey bu.
Sizin Scriptiniz Bu Testlerden Geçebilir mi?
Pinova ile kullanıcı ve bayi şifreleri kurulumdan itibaren tuzlu hash yöntemiyle korunur, ödeme bilgileri kendi veritabanınıza hiç dokunmaz; güvenlik "sonradan eklenecek" bir madde değil, altyapının bir parçasıdır.
E-pin scriptimde şifreler nasıl saklandığını nereden anlarım?
Veritabanındaki kullanıcılar tablosuna bakın. Şifre sütunu sabit 32 veya 40 karakterse ve yanında ayrı bir "salt" sütunu yoksa büyük olasılıkla MD5 veya SHA-1 gibi zayıf, tuzsuz bir yöntem kullanılıyordur. bcrypt hash'leri genelde değişken uzunlukta olur ve "$2y$" ile başlar.
Şifre hash'lenmişse hesabım tamamen güvende midir?
Güçlü hashing önemli bir katmandır ama tek başına yeterli değildir. Oturum yönetimi, giriş denemesi limitleri, HTTPS kullanımı ve sunucu güvenliği gibi diğer faktörler de bir arada olmalıdır. Pinova bu katmanların tamamını birlikte ele alır.
Var olan e-pin sitemin şifreleme yöntemini sonradan değiştirebilir miyim?
Teknik olarak mümkündür ancak dikkat gerektirir: mevcut kullanıcıların şifreleri genelde toplu olarak yeniden hash'lenemez, çünkü orijinal şifre bilinmiyordur. Genelde yapılan, kullanıcı bir sonraki girişinde şifresini doğrularken arka planda yeni algoritmaya geçirmektir (rehash-on-login).
Pinova'yı kendi sunucuma kurduğumda güvenlik sorumluluğu tamamen bende mi olur?
Sunucu güvenliği (güncel PHP sürümü, firewall, SSL sertifikası) sizin sorumluluğunuzdadır, ancak Pinova'nın kendi uygulama katmanı — şifreleme, oturum yönetimi, yetkilendirme — hazır ve test edilmiş olarak gelir. Yani sıfırdan bir güvenlik mimarisi kurmanız gerekmez.