---
title: "Credential Stuffing Nedir? Nasıl Tespit Edilir ve Önlenir?"
description: "Credential stuffing, sızan kullanıcı adı ve şifre çiftlerinin başka sitelerde otomatik denenmesidir. İşleyişi, loglardaki izleri ve önlemleri."
url: https://proxynet.io/tr/blog/what-is-credential-stuffing
date: 2026-09-28
author: "Acar Diveroli"
category: "Proxy 101"
lang: tr
---

# Credential Stuffing Nedir? Nasıl Tespit Edilir ve Önlenir?

Küçük bir online mağazanın müşteri veritabanı sızıyor. Birkaç hafta sonra bir video yayın servisi, daha önce hiç sorun çıkarmamış hesaplara yoğun giriş denemeleri görüyor. Bir oyun platformu aynı dalgayı yaşıyor, ardından bir banka. Bu sitelerin hiçbirinden veri sızmadı. Mağazadan sızan e-posta ve şifre çiftleri onların giriş sayfalarında da işe yaradı, çünkü pek çok kişi her yerde aynı şifreyi kullanıyor.

Bu yazıda credential stuffing'e savunma tarafından bakıyoruz: kaba kuvvet saldırısından ve password spraying'den farkını, neden binlerce IP adresi üzerinden geldiğini, loglarınızda bıraktığı izleri, onu durduran önlemleri ve kullanıcıların neler yapabileceğini anlatıyoruz. Yazıda iki kısa Python örneği var; ikisi de savunma amaçlı.

> **Not: Kısa cevap**
>
> Credential stuffing (kimlik bilgisi doldurma), bir siteden sızmış kullanıcı adı ve şifre çiftlerinin başka sitelerin giriş sayfalarında otomatik olarak denendiği bir saldırıdır. Saldırgan, insanların şifrelerini tekrar kullandığına güvenir; saldırı yalnız şifresini tekrar kullanan kullanıcılarda sonuç verir. Site sahipleri onu çok faktörlü kimlik doğrulamayla, sızıntı listelerinde geçen şifreleri reddederek, hesap başına başarısız deneme sayısını sınırlayarak ve bot tespitiyle durdurur. Yalnız IP adresi engellemek işe yaramaz, çünkü denemeler çok sayıda adrese dağıtılır. Kullanıcılar ise her hesap için ayrı bir şifre ya da geçiş anahtarı (passkey) kullanarak kendilerini korur.

## Credential stuffing nedir?

Credential stuffing, çalınmış giriş bilgilerinin toplu hâlde yeniden kullanılmasıdır. Saldırgan, başka bir servisin daha önceki bir veri ihlalinden alınmış ve gerçek olduğu bilinen çiftlerle başlar, bunları otomatik bir yazılımla hedef sitenin giriş formuna gönderir. Çiftlerin çoğu tutmaz. Tutanlar, sahibinin ihlale uğrayan sitede ve hedef sitede aynı şifreyi kullandığı hesaplardır.

[OWASP Credential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) bu saldırıyı, "başka bir sitenin ihlalinden elde edilen" kullanıcı adı ve şifre çiftlerinin denenmesi olarak tanımlar. Hedef sitenin kendi şifreleri çalınmamıştır, kodunda da bir hata yoktur; zayıf nokta şifrelerin tekrar kullanılmasıdır.

Saldırganın amacı hesap ele geçirmedir (account takeover, ATO): içinde değerli bir şey bulunan bir hesaba giriş yapabilmek. Bu değer sadakat puanları, kayıtlı bir ödeme kartı, hediye kartı bakiyesi, kişisel veriler ya da yalnızca spam göndermek için güvenilir görünen bir hesap olabilir. Ele geçirilen hesaplar çoğu zaman yeniden satılır.

## Credential stuffing saldırısı nasıl işler?

Genel hatlarıyla bir saldırı beş aşamadan geçer. Bu aşamaları bilmek, her önlemi nereye koyacağınıza karar vermenizi kolaylaştırır.

1. **Başka bir yerde yaşanan ihlal.** Bir servis ele geçirilir; e-postaları ve şifreleri (ya da sonradan kırılan şifre özetlerini) içeren kullanıcı listesi dolaşıma girer.
1. **Toplama.** Pek çok ihlalden sızan çiftler büyük listelerde birleştirilir. Eski sızıntılar yıllarca değerini korur, çünkü birçok kişi tekrar kullandığı şifreyi hiç değiştirmez.
1. **Otomasyon.** Bir yazılım, çiftleri hedefin giriş formuna ya da giriş API'sine bir insanın yazabileceğinden çok daha hızlı gönderir.
1. **Dağıtım.** Basit IP başına sınırlara takılmamak için istekler çok sayıda IP adresine yayılır. Bunun için genellikle virüslü cihazlardan oluşan botnet'ler ya da kiralık proxy ağları kullanılır; böylece her adres yalnızca birkaç deneme gönderir.
1. **İsabetlerin kullanılması.** Çalışan çiftlerin değeri kontrol edilir, sonra bu hesaplar kullanılır ya da satılır. Bazı saldırganlar gerçek sahibini dışarıda bırakmak için e-postayı ve şifreyi hemen değiştirir.

Birinci aşama başka birinin sunucusunda yaşanır. Sizin önlemleriniz 3. ile 5. aşamalar arasında devreye girer: otomatik girişleri pahalı hâle getirmek, doğru şifreyi tek başına yetersiz kılmak ve ele geçirilen hesabı erkenden fark etmek. Şifreleri sızıntı listeleriyle karşılaştırmak ise 2. aşamayı saldırganın aleyhine çevirir.

## Credential stuffing, kaba kuvvet ve password spraying farkı

Üç saldırı da giriş sayfalarını hedef alır, ancak farklı girdiler kullanır ve farklı izler bırakır. Aşağıdaki tanımlar OWASP rehberini izler.

| Saldırı | Ne denenir | Örüntü | Deneme başına tipik başarı oranı | Temel önlem |
|---|---|---|---|---|
| Kaba kuvvet saldırısı (brute force) | Tek hesaba karşı çok sayıda şifre | Tek hesap, çok şifre | Şifre zayıf değilse çok düşük | Hesap başına deneme sınırı, uzun şifreler |
| Password spraying | Çok sayıda hesaba karşı tek bir yaygın şifre | Çok hesap, bir ya da birkaç şifre | Düşük, zayıf şifrelere dayanır | Yaygın şifrelerin engel listesi, MFA |
| Credential stuffing | Sızmış gerçek çiftler, her biri bir kez | Çok hesap, her birine bir şifre | Daha yüksek, çünkü her çift bir yerde gerçekti | MFA, sızmış şifre kontrolü, bot tespiti |

Beş yanlış şifreden sonra hesabı kilitlemek kaba kuvvet saldırısını durdurur. Credential stuffing'e ise neredeyse hiç dokunmaz, çünkü her hesap genellikle tek bir deneme görür.

## Bu saldırılarda neden proxy ve residential IP'ler görülür?

Yirmi başarısız girişten sonra bir IP adresini engellemek koruma gibi görünür; saldırganlar da bu yüzden istekleri çok sayıda adres üzerinden geçirir: ele geçirilmiş ev modemleri, virüslü cihazlar, bulut sunucuları ve proxy ağları. Ev bağlantılarına ait adresleri engellemek zordur, çünkü gerçek müşteriler de aynı adresleri kullanıyor olabilir.

OWASP rehberinin IP engelleme ve IP itibarının "tek ya da birincil savunma olarak kullanılmaması gerektiğini" söylemesinin nedeni budur. Pratikte üç sorun vardır:

- **Adres başına düşük hacim.** Her adres bir ya da iki deneme gönderdiğinde IP başına hiçbir eşik tetiklenmez.
- **Paylaşılan adresler.** Mobil operatörler ve birçok ev interneti sağlayıcısı, çok sayıda müşteriyi tek bir genel adresin arkasına koyar (carrier-grade NAT). Bu adresi engellemek gerçek kullanıcıları dışarıda bırakabilir.
- **Hızlı değişim.** Adresler çabuk değişir; engel listesi daha yazılırken eskir.

IP verisi yine de birkaç sinyalden biri olarak işe yarar. Yüksek bir [IP fraud score](/tr/blog/ip-fraud-score) ya da adresin bir [IP kara listesinde](/tr/blog/ip-blacklist) görünmesi, girişin risk puanını yükseltip doğrudan engelleme yerine ek bir kontrolü tetikleyebilir.

Kendi ağımızla ilgili bir not: Proxynet'in [Hizmet Şartları](/tr/tos) yetkisiz erişim denemelerini yasaklar; kabul edilebilir kullanım kurallarını çiğneyen hesaplar önceden haber verilmeden askıya alınabilir. Kendi sitenizi başka ülkelerden test etmek gibi meşru kullanımlar [veri güvenliği](/tr/data-security) sayfamızda anlatılıyor.

## Saldırı altında olduğunuzu gösteren sinyaller

Hiçbir sinyal tek başına saldırıyı kanıtlamaz, ancak birkaçı bir araya geldiğinde gözden kaçması zordur. Bir izleme panosuna koymaya değer olanlar şunlardır:

- **Başarısız giriş oranında sıçrama.** Sızmış çiftlerin çoğu eşleşmez; bu yüzden bir saldırı dalgası normalde sabit duran oranı birden yukarı iter.
- **Çok sayıda "bilinmeyen kullanıcı" hatası.** Sızıntı listelerinde sizde hiç kayıt olmamış e-postalar da bulunur.
- **Çok hesap, her birine tek deneme.** Farklı kullanıcı adı sayısının deneme sayısına oranı bire yakındır; bu, kaba kuvvet örüntüsünün tam tersidir.
- **Çok IP adresi, her birinden az deneme;** bunlar çoğu zaman size normalde gerçek kullanıcı göndermeyen ağlardan gelir.
- **Binlerce "farklı" kullanıcıda aynı istemci parmak izi.** Bu sinyalleri [bot tespitinin nasıl çalıştığını](/tr/blog/how-bot-detection-works) anlattığımız yazıda bulabilirsiniz.
- **Sayfa görüntülemesi olmayan girişler.** Giriş sayfasını, betiklerini ya da görsellerini yüklemeden doğrudan giriş API'sine giden istekler.
- **Başarılı girişten sonra olanlar.** Girişten birkaç saniye sonra e-posta, şifre ya da ödeme bilgisi değişikliği.

Çoğu zaman kullanıcılar durumu sizden önce fark eder: [bankadan gelen şüpheli giriş uyarısı](/tr/blog/bank-suspicious-login-location) ya da kendilerinin yapmadığı bir girişi bildiren "yeni oturum açıldı" e-postası. Bunu size bildirmelerini kolaylaştırın.

## Sitenizde credential stuffing nasıl önlenir?

OWASP rehberi önlemleri kabaca değerlerine göre sıralar. Aşağıdaki liste bu yaklaşımı korur ve [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) (Revizyon 4, Ağustos 2025'ten beri nihai) standardının şifre sistemlerinden istediklerini ekler.

1. **Çok faktörlü kimlik doğrulama.** OWASP, MFA'yı şifre saldırılarına karşı "açık ara en iyi savunma" olarak nitelendirir: sızan şifre doğru olsa bile tek başına yetmez. Yönetici hesaplarında ve riskli işlemlerde zorunlu tutun, yukarıdaki sinyaller tetiklendiğinde de devreye sokun.
1. **Geçiş anahtarları (passkey).** Geçiş anahtarı, şifrenin yerini kullanıcının cihazında tutulan bir anahtar çiftine bırakır. [FIDO Alliance](https://fidoalliance.org/passkeys/) geçiş anahtarlarını oltalamaya dayanıklı olarak tanımlar; sunucunuzda sızabilecek ya da başka yerde kullanılabilecek ortak bir sır bulunmaz. Yalnızca geçiş anahtarıyla giriş yapılan bir hesapta credential stuffing'in deneyebileceği hiçbir şey yoktur.
1. **Sızmış şifre kontrolü.** NIST SP 800-63B'nin 3.1.1.2. bölümüne göre doğrulayıcılar yeni bir şifreyi "yaygın kullanılan, tahmin edilebilir ya da ele geçirilmiş" değerlerden oluşan bir engel listesiyle karşılaştırmak zorundadır. Bu kontrolü kayıtta ve şifre değişikliğinde yapın; ele geçirildiğine dair kanıt varsa şifre değişikliğini zorunlu kılın.
1. **Yalnız IP'yi değil hesabı da izleyen deneme sınırları.** NIST'in 3.2.2. bölümü, tek bir hesaptaki art arda başarısız deneme sayısını en fazla 100 ile sınırlar. Bunu cihaz, IP aralığı ve giriş uç noktası başına sınırlarla birleştirin; hesapları kilitlemek yerine yanıtları adım adım yavaşlatın.
1. **Bot yönetimi.** İstemcinin JavaScript çalıştırıp çalıştırmadığını ve bağlantı parmak izinin beyan ettiği tarayıcıyla uyuşup uyuşmadığını kontrol edin. CAPTCHA yalnızca bir hız kesicidir, savunmanın tamamı değildir.
1. **Her hataya aynı yanıt.** "Yanlış şifre" ve "böyle bir kullanıcı yok" durumlarında aynı mesajı, benzer bir süre içinde döndürün; böylece giriş formu hangi e-postaların hesabı olduğunu yoklamak için kullanılamaz.
1. **Kullanıcıyı bilgilendirin, girişten sonra hesabı izleyin.** Yeni cihazdan yapılan girişlerde ve hesap değişikliklerinde uyarı gönderin, bu değişikliklerden önce ikinci bir doğrulama adımı isteyin.

## Kod: k-anonymity ile sızmış şifre kontrolü

Have I Been Pwned'in [Pwned Passwords API](https://haveibeenpwned.com/API/v3#PwnedPasswords) servisi, bir şifreyi ne kendisini ne de tam özetini göndermeden bilinen sızıntılarla karşılaştırmanıza izin verir. Yalnızca SHA-1 özetinin ilk beş karakterini gönderirsiniz; servis bu karakterlerle başlayan bütün özet soneklerini kaç kez görüldükleriyle birlikte döndürür, siz de kendi sonekinizi yerelde ararsınız. Bu yönteme k-anonymity modeli denir. Aralık (range) API'si anahtar istemez; `Add-Padding` başlığı ise yanıta sayısı 0 olan sahte satırlar ekler, böylece yanıtın boyutu bir şey ele vermez.

```python
import hashlib
import time
import urllib.error
import urllib.request

API = "https://api.pwnedpasswords.com/range/"

def breach_count(password: str, retries: int = 3) -> int:
    """Şifrenin Pwned Passwords'te kaç kez geçtiğini döndürür (0 = bulunamadı)."""
    digest = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = digest[:5], digest[5:]
    request = urllib.request.Request(
        API + prefix,
        headers={"User-Agent": "example-signup-check", "Add-Padding": "true"},
    )
    for attempt in range(retries):
        try:
            with urllib.request.urlopen(request, timeout=5) as response:
                body = response.read().decode("utf-8")
            break
        except (urllib.error.URLError, TimeoutError):
            if attempt == retries - 1:
                raise
            time.sleep(2 ** attempt)
    for line in body.splitlines():
        candidate, _, count = line.partition(":")
        if candidate == suffix:
            return int(count)  # dolgu satırlarının sayısı 0'dır
    return 0

if __name__ == "__main__":
    for pw in ["password123", "correct horse battery staple", "vX9#qL2-mT8!rW4zK7"]:
        hits = breach_count(pw)
        verdict = "reject: seen in breaches" if hits else "not in the breach list"
        print(f"{pw!r}: {hits} -> {verdict}")
```

Betiği çalıştırdığınızda ilk iki şifre sızıntılarda bulunmuş olarak döner; sayılar veri kümesi güncellendikçe artar. Rastgele dizi ise 0 döndürür. Bir kayıt formunda `breach_count` fonksiyonunu sunucu tarafında çağırın, sıfırdan farklı her sonucu anlaşılır bir mesajla reddedin ve API'ye ulaşılamazsa ne olacağına önceden karar verin.

## Kod: giriş loglarında credential stuffing dalgasını yakalamak

Çoğu site her giriş denemesini zaten loglar. Aşağıdaki betik `time`, `ip`, `username` ve `result` sütunları olan bir CSV logunu okur, denemeleri dakikalara göre gruplar ve başarısızlık oranı olağan dışı olan dakikaları, bilinmeyen kullanıcı adlarının payı ile farklı hesap ve adres sayısıyla birlikte yazdırır.

```python
import csv
from collections import defaultdict

ALERT_FAIL_RATE = 0.50
MIN_ATTEMPTS = 50

# Giriş denemelerini birer dakikalık gruplara ayır.
buckets = defaultdict(lambda: {"total": 0, "failed": 0, "unknown": 0, "users": set(), "ips": set()})
with open("logins.csv", newline="") as f:
    for row in csv.DictReader(f):
        b = buckets[row["time"][:16]]          # "2026-09-28T10:41"
        b["total"] += 1
        b["users"].add(row["username"])
        b["ips"].add(row["ip"])
        if row["result"] != "ok":
            b["failed"] += 1
        if row["result"] == "unknown_user":
            b["unknown"] += 1

for minute in sorted(buckets):
    b = buckets[minute]
    fail_rate = b["failed"] / b["total"]
    unknown_share = b["unknown"] / b["total"]
    if b["total"] >= MIN_ATTEMPTS and fail_rate >= ALERT_FAIL_RATE:
        print(f"{minute}  attempts={b['total']}  failed={fail_rate:.0%}  "
              f"unknown-user={unknown_share:.0%}  accounts={len(b['users'])}  ips={len(b['ips'])}")
```

Normal trafiğin içine yapay bir saldırı dalgası eklenmiş bir test logunda çıktı şöyle görünür:

```text
2026-09-28T10:40  attempts=80  failed=78%  unknown-user=49%  accounts=80  ips=69
2026-09-28T10:41  attempts=80  failed=79%  unknown-user=45%  accounts=80  ips=70
```

Seksen hesap, neredeyse o kadar adres ve kullanıcı adlarının yarısı bilinmiyor: credential stuffing örüntüsü tam olarak budur. Eşikleri kendi normal trafiğinize göre belirleyin.

## Kullanıcılar ne yapabilir?

Credential stuffing yalnızca tekrar kullanılan şifrelerde işe yarar; bu yüzden kullanıcıların elinde gerçek bir kontrol vardır.

- **Bir şifre yöneticisi kullanın;** böylece her site kendine ait rastgele bir şifre alır.
- **İki faktörlü kimlik doğrulamayı açın;** işe e-posta ve bankacılık hesaplarından başlayın. Doğrulayıcı uygulama ya da güvenlik anahtarı, SMS kodundan daha güvenlidir.
- **Destekleyen sitelerde geçiş anahtarına geçin.** Sızacak ya da tekrar kullanılacak bir şifre kalmaz.
- **E-posta adresinizi Have I Been Pwned'de kontrol edin** ve tekrar kullandığınız her şifreyi değiştirin.
- **Sizin yapmadığınız "yeni oturum" uyarılarını ciddiye alın:** şifreyi değiştirin ve diğer oturumları kapatın.
- **Tanımadığınız ağlar üzerinden giriş yapmaktan kaçının.** Bir yabancının işlettiği ücretsiz proxy trafiğinizi okuyabilir; ayrıntılar [Ücretsiz Proxy ve Web Proxy Siteleri Güvenli mi?](/tr/blog/are-free-proxies-safe) yazısında.

## En çok nerede önem taşır?

- **Online mağazalar ve pazaryerleri.** Kayıtlı kartlar, hediye kartları ve sadakat puanları hesapları ele geçirmeye değer kılar. Mağazaların kendi vitrinlerini nasıl test ettiğini [e-ticaret](/tr/e-commerce-proxy) sayfamızda bulabilirsiniz.
- **Bankalar ve fintech şirketleri.** Ele geçirilen hesaptan para doğrudan başka hesaplara aktarılabilir. [Finans](/tr/finance) sayfası, finans ekiplerinin herkese açık sayfalarını başka bölgelerden nasıl kontrol ettiğini anlatıyor.
- **Yayın ve oyun servisleri.** Paylaşılan ve yeniden satılan hesaplar, çalınmış girişler için sürekli bir pazar oluşturur.
- **Kişisel veri toplayan her site.** Ele geçirilen bir hesap kullanıcının kayıtlı bilgilerini açığa çıkarır; bu yalnızca bir dolandırıcılık sorunu değil, kişisel verilerin korunmasıyla da ilgili bir sorundur. Veri ekipleri için işin bu tarafını [kazınmış veri setlerindeki kişisel verileri](/tr/blog/personal-data-in-scraped-datasets) anlattığımız yazı ele alıyor.

## Sık yapılan hatalar

- **IP engellemeye güvenmek.** Dağıtık saldırılara karşı işe yaramaz.
- **Birkaç başarısız denemeden sonra hesabı kilitlemek.** Saldırganların müşterilerinizi dışarıda bırakmasına imkân verir.
- **"Yanlış şifre" ve "böyle bir hesap yok" için farklı hata mesajları.** Giriş formunuzu ücretsiz bir e-posta sorgulama aracına dönüştürür.
- **Web formunu koruyup API'yi korumamak.** Mobil uygulamaların ve eski API sürümlerinin çoğu zaman daha gevşek sınırları olan kendi giriş uç noktası vardır.
- **Düzenli şifre değişikliğini zorunlu tutmak.** NIST SP 800-63B bunun yapılmamasını ister; şifre değişikliğini yalnızca ele geçirildiğine dair kanıt olduğunda zorunlu kılın.
- **Yalnızca girişi izlemek.** Hesap ele geçirme en açık hâliyle girişten sonra olanlarda görünür.

## Karar rehberi

| Durumunuz | İlk yapılacak iş |
|---|---|
| Başarısız girişler sıçradı ve kullanıcı adlarının çoğu bilinmiyor | Durumu credential stuffing olarak ele alın: riskli oturumlarda ek doğrulama adımlarını artırın, yeni cihazlardan gelen başarılı girişlerde ikinci bir doğrulama isteyin |
| Güvenlik ekibi olmayan küçük bir site işletiyorsunuz | MFA ekleyin, kayıtta ve şifre değişikliğinde sızmış şifre kontrolü yapın, girişin önüne yönetilen bir bot koruma servisi koyun |
| Yönetici ya da personel hesapları yalnızca şifreyle giriş yapıyor | Bu hesaplar için MFA ya da geçiş anahtarını hemen zorunlu kılın |
| Müşteriler kendilerinin yapmadığı girişleri bildiriyor | Etkilenen hesaplarda şifre sıfırlamayı zorunlu kılın, kullanıcıları bilgilendirin ve girişten sonra neyin değiştiğini inceleyin |
| Bugün yalnızca IP engelliyorsunuz | Bunu bir sinyal olarak tutun; hesap ve uç nokta başına sınırlar ile cihaz kontrolleri ekleyin |
| Şifrelerini tekrar kullanan bir kullanıcısınız | Bir şifre yöneticisine geçin ve e-postadan başlayarak iki faktörlü kimlik doğrulamayı açın |

## Sıkça sorulan sorular

### Credential stuffing yasa dışı mı?

Evet. Başka birinin hesabına izinsiz giriş yapmak, hangi araç kullanılırsa kullanılsın, çoğu ülkenin bilişim suçları mevzuatında yetkisiz erişim sayılır. Test yalnızca size ait ya da test etmek için yazılı izin aldığınız sistemlerde yasaldır.

### Credential stuffing ile veri ihlali arasındaki fark nedir?

Veri ihlali, tek bir servisten verinin çalınmasıdır. Credential stuffing ise bundan sonra gelir: çalınan çiftler başka servislerde denenir. Saldırıya uğrayan sitenin kendisi hiç ihlale uğramamış olabilir.

### CAPTCHA credential stuffing'i durdurur mu?

Saldırıyı yavaşlatır ve maliyetini artırır, ancak tam bir savunma değildir. OWASP onu çok faktörlü kimlik doğrulamanın arkasında, birkaç katmandan biri olarak sayar.

### Üç yanlış şifreden sonra hesabı kilitlemek neden yetmez?

Credential stuffing'de her hesap genellikle tek bir deneme alır, bu yüzden kilit nadiren devreye girer. Devreye girdiği yerde de gerçek kullanıcıları dışarıda bırakmak için kullanılabilir. Hesap, cihaz ve uç nokta düzeyinde ayrı ayrı uygulanan sınırlar daha iyi sonuç verir.

### Şifreleri Pwned Passwords ile kontrol etmek kullanıcılarım için güvenli mi?

Aralık API'sinde yalnızca şifrenin SHA-1 özetinin ilk beş karakterini gönderirsiniz; eşleştirme sizin sunucunuzda yapılır. Servis ne şifrenin tamamını ne de tam özetini görür.

### Geçiş anahtarları credential stuffing'i bitirir mi?

Yalnızca geçiş anahtarıyla giriş yapılan hesaplar için evet: denenecek, tekrar kullanılabilir bir şifre yoktur. Ancak bir site şifreyi yedek yöntem olarak kabul etmeye devam ettiği sürece, bu yedek yöntem de aynı korumalara ihtiyaç duyar.

## Özet

İnsanlar şifrelerini tekrar kullandığı için credential stuffing, tek bir sitedeki ihlali pek çok sitede hesap ele geçirmeye dönüştürür. Saldırı çok sayıda IP adresine yayıldığından yalnızca IP engellemek onu durdurmaz. İşe yarayan önlemler şunlardır: çok faktörlü kimlik doğrulama ya da geçiş anahtarları, NIST SP 800-63B'nin istediği gibi sızıntı listelerinde geçen şifrelerin reddedilmesi, hesaba ve cihaza bağlı deneme sınırları, bot tespiti ve girişten sonra olanların izlenmesi. Kullanıcılar da şifre yöneticisi ve her hesaba ayrı şifreyle kendi taraflarındaki kapıyı kapatır. Kendi giriş akışlarınızı ve sayfalarınızı başka bölgelerden meşru biçimde test etmek için [proxy hizmetlerimize](/tr/proxy) ve [Residential Proxy](https://proxynet.io/tr/residential-proxy) sayfasına göz atın.