MQTT kullanıcı adı ve şifre ile kimlik doğrulama, bir istemcinin kimliğini broker'a kanıtlamasının en yaygın yoludur ve aynı zamanda en sık yanlış yapılandırılan yöntemdir. Bu rehberde kimlik bilgilerinin CONNECT paketinde tam olarak nasıl taşındığını, neden yalnızca TLS içinde güvenli olduklarını, yanlış olduklarında hangi reason code'ları aldığınızı ve cihaz başına bir kimlik bilgisi setinin nasıl yönetileceğini göreceksiniz.
Kimlik Bilgileri CONNECT Paketinde Nasıl Taşınır?
Her MQTT oturumu istemciden gelen bir CONNECT paketiyle başlar. Değişken başlığı bağlantı bayraklarını içerir; bunlardan ikisi User Name Flag ve Password Flag'dir. Bu bayraklar ayarlandığında payload, client ID'den ve isteğe bağlı Will mesajından hemen sonra kullanıcı adını UTF-8 metin, şifreyi ise ikili veri olarak taşır.
CONNECT
Protocol name: MQTT
Protocol level: 5 (MQTT 5.0) or 4 (MQTT 3.1.1)
Connect flags: username=1, password=1, clean start=1
Keep alive: 60
Payload:
Client ID: sensor-0042
Username: YOUR_USERNAME
Password: YOUR_PASSWORD <- raw bytes, not hashed
MQTT katmanında hash, challenge veya şifreleme yoktur. Şifre olduğu gibi gönderilir. 1883 portundaki TCP akışını okuyabilen herkes, bir paket yakalama aracıyla şifreyi saniyeler içinde okuyabilir.
Bilinmesi gereken birkaç protokol detayı:
- MQTT 3.1.1'de şifre yalnızca bir kullanıcı adı da gönderiliyorsa gönderilebilir. MQTT 5.0 bunu gevşetti ve şifrenin tek başına gönderilmesine izin verdi, ancak çoğu broker hâlâ ikisini birden bekler.
- Şifre alanı ikili olduğundan token'lar dahil rastgele baytlar taşıyabilir. MQTT JWT kimlik doğrulama gibi token tabanlı yöntemler aynı alanı bu şekilde yeniden kullanır.
- MQTT 5.0 ayrıca challenge-response mekanizmaları için bir Authentication Method özelliği ve AUTH paketleri aracılığıyla gelişmiş kimlik doğrulamayı tanımlar. Kullanıcı adı ve şifre ise yaygın temel olmaya devam eder.
Şifrelerle Birlikte TLS Neden Zorunludur?
Şifre ağda düz metin olarak geçtiği için, güvenilmeyen herhangi bir ağda TLS olmadan MQTT kullanıcı adı ve şifre ile kimlik doğrulama, hiç kimlik doğrulama olmamasından pek de iyi değildir. TLS, CONNECT paketi dahil tüm oturumu şifreler ve istemcinin kimlik bilgilerini toplayan bir sahtekârla değil gerçek broker'la konuştuğunu doğrulamasını sağlar.
| Port | Taşıma | Kimlik bilgileri için güvenli mi? |
|---|---|---|
| 1883 | Düz TCP üzerinden MQTT | Hayır, şifre hatta görünür |
| 8883 | TLS üzerinden MQTT | Evet, sertifika doğrulamasıyla |
| 8083 | WebSocket üzerinden MQTT | Hayır |
| 8084 | Güvenli WebSocket üzerinden MQTT (/mqtt) |
Evet |
ConnectMQ'da kimlik bilgisi gönderdiğiniz her durumda cihazlar ve servisler için 8883, tarayıcılar için 8084 portunu kullanın. Broker, masaüstü ve sunucu işletim sistemlerindeki standart CA paketleri tarafından güvenilen bir Let's Encrypt sertifikası sunar. Gömülü istemcilerin kök CA'yı firmware'e dahil etmesi gerekir; bu adımı MQTT TLS yapılandırması rehberi ele alır.
Sertifikayı da doğrulayın. Doğrulamayı devre dışı bırakmak (insecure, setInsecure(), rejectUnauthorized: false) size pasif dinlemeye karşı şifreleme sağlar, ancak bağlantıyı araya girip kendi sertifikasını sunan bir saldırgana karşı hiçbir koruma sağlamaz.
Kullanıcı Adı ve Şifre ile Bağlanmak
Örnekler, portalda bir broker oluşturduğunuzda aldığınız YOUR_USERNAME, YOUR_PASSWORD ve YOUR_CLIENT_ID yer tutucularını kullanır. Henüz bir broker kurmadıysanız bulut MQTT broker rehberi barındırma seçeneklerini adım adım anlatır.
Python (paho-mqtt 2.x)
import os
import ssl
import paho.mqtt.client as mqtt
HOST = os.environ.get("MQTT_HOST", "YOUR_BROKER_HOST")
USERNAME = os.environ["MQTT_USERNAME"] # asla kaynak kontrolüne sabit olarak yazmayın
PASSWORD = os.environ["MQTT_PASSWORD"]
CLIENT_ID = os.environ["MQTT_CLIENT_ID"]
def on_connect(client, userdata, flags, reason_code, properties):
if reason_code.is_failure:
print("Rejected:", reason_code) # ör. Bad user name or password
client.disconnect()
return
print("Authenticated")
client.publish(f"devices/{CLIENT_ID}/status", "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.connect(HOST, 8883, keepalive=60)
client.loop_forever()
Komut Satırı
mosquitto_pub -h YOUR_BROKER_HOST -p 8883 \
--cafile /etc/ssl/certs/ca-certificates.crt \
-i YOUR_CLIENT_ID -u YOUR_USERNAME -P "$MQTT_PASSWORD" \
-t 'devices/YOUR_CLIENT_ID/status' -m online -V mqttv5
Şifreyi komut satırına yazmak yerine bir ortam değişkeninden okuyun; aksi takdirde kabuk geçmişine ve süreç listelerine düşer.
Kimlik Bilgileri Yanlış Olduğunda Ne Olur?
Broker, CONNECT'e bir CONNACK ile yanıt verir. Kod, sorunun kimlik bilgilerinde mi yoksa yetkilendirmede mi olduğunu söyler:
| Durum | MQTT 3.1.1 CONNACK | MQTT 5.0 reason code |
|---|---|---|
| Kabul edildi | 0x00 | 0x00 Success |
| Client ID reddedildi | 0x02 Identifier rejected | 0x85 Client Identifier not valid |
| Yanlış kullanıcı adı veya şifre | 0x04 Bad user name or password | 0x86 Bad User Name or Password |
| Geçerli kimlik bilgileri, izin yok | 0x05 Not authorized | 0x87 Not authorized |
Ayrıntılı sorun giderme adımları MQTT bağlantısı reddedildi: not authorized yazısında yer alıyor. Her istemci için iki pratik kural geçerlidir:
- Sıkı bir döngüde hemen yeniden denemeyin. Yanlış kimlik bilgileri kendiliğinden düzelmez ve birçok broker hızlı başarısızlıkları saldırı olarak değerlendirir. ConnectMQ, tekrarlanan başarısız girişlerden sonra IP adreslerini engeller; bu nedenle broker'ı bombardımana tutan yanlış yapılandırılmış bir filo kendi kendini kilitleyebilir.
- Jitter ile üstel geri çekilme (exponential backoff) kullanın ve kimlik doğrulama hatalarını ağ hatalarından ayrı olarak günlüklerde veya cihaz durumunda gösterin.
Cihaz Başına Kimlik Bilgileri: Neden ve Nasıl?
Çoğu projenin başladığı kestirme yol, her cihaza gömülmüş tek bir ortak kullanıcı adı ve şifredir. İlk gün çalışır, sonrasında ise sorun çıkarır:
- Sızdırılan tek bir cihaz tüm filoyu açığa çıkarır.
- Hepsini yeniden flaşlamadan tek bir cihazın erişimini iptal edemezsiniz.
- Günlükler hangi cihazın sorun çıkardığını söyleyemez.
Cihaz başına kimlik bilgileri bu üç sorunu da çözer. Kendi barındırdığınız bir Mosquitto broker'da bir şifre dosyası tutarsınız:
# Dosyayı ilk kullanıcıyla oluşturun, ardından -c olmadan diğerlerini ekleyin
mosquitto_passwd -c /etc/mosquitto/passwd sensor-0001
mosquitto_passwd /etc/mosquitto/passwd sensor-0002
# mosquitto.conf
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
allow_anonymous false
password_file /etc/mosquitto/passwd
Dosya şifrelerin kendisini değil, tuzlanmış hash'lerini saklar ve değişikliklerden sonra broker'ın yeniden yüklenmesi gerekir. Bunu kendiniz işletmek, TLS sertifikasını yenilemeyi ve dosyayı örnekler arasında senkronize tutmayı da gerektirir.
ConnectMQ'da Cihaz Başına Kimlik Bilgileri
ConnectMQ ile kimlik bilgilerini broker sizin için oluşturur. Portalda bir broker oluşturduğunuzda bir kullanıcı adı, şifre ve client ID alırsınız; client ID, verilen kimlik bilgilerine bağlıdır. Bu bağlama önemlidir: çalınan bir şifre rastgele bir client ID ile kullanılamaz ve iki cihaz, aynı bağlı kimlik için yarışacakları için tek bir kimlik bilgisi setini sessizce paylaşamaz.
Yönetilen bir broker'da önerilen uygulamalar:
- Her cihaz veya servis için ayrı bir kimlik bilgisi seti verin ve hangi fiziksel cihazın hangi client ID'yi taşıdığını kaydedin.
- Şifreyi kaynak kodda değil, cihazdaki korumalı depolamada saklayın. Bkz. cihazlarda MQTT kimlik bilgilerini güvenli tutmak.
- Yalnızca 8883 veya 8084 portundan, sertifika doğrulamasıyla bağlanın.
- Değişikliğe hazırlıklı olun: kimlik bilgisi yenileme rehberi, bir filo genelinde kimlik bilgilerini kesinti olmadan nasıl değiştireceğinizi gösterir.
Tenant'lar birbirinden izole edilmiştir; bu nedenle broker'ınız için verilen kimlik bilgileri yalnızca broker'ınızın trafiğine erişim sağlar. Kotalar ve flood koruması plan bazında uygulanır; bu da ele geçirilmiş tek bir istemcinin verebileceği zararı sınırlar.
Kullanıcı Adı ve Şifre ile Diğer Yöntemlerin Karşılaştırması
| Yöntem | Güçlü yanı | Zayıf yanı |
|---|---|---|
| TLS üzerinden kullanıcı adı ve şifre | Basit, her istemci kütüphanesi tarafından desteklenir | Statik sır; saklanması ve yenilenmesi gerekir |
| İstemci sertifikaları (mTLS) | Güçlü kimlik, hatta paylaşılan sır yok | İşletilmesi gereken sertifika yaşam döngüsü ve PKI |
| Şifre alanında JWT | Kısa ömürlü, claim taşır | Bir token yayıncısı ve cihazlarda saat senkronizasyonu gerekir |
Çoğu filo için doğrulanmış TLS üzerinden cihaz başına benzersiz şifreler sağlam bir temeldir. MQTT güvenliği en iyi uygulamaları rehberi, bunun üzerine eklenen katmanları ele alır.
ConnectMQ ile Başlayın
Şifre dosyalarıyla ve sertifika yenilemeleriyle uğraşmayın. ConnectMQ'nun sunduğu barındırılan MQTT broker, 8883 ve 8084 portlarında TLS, client ID'lere bağlı oluşturulmuş kimlik bilgileri ve tekrarlanan başarısız girişler için IP engelleme sağlar. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun.
Sık Sorulan Sorular
MQTT kullanıcı adı ve şifre ile kimlik doğrulama güvenli mi?
Sertifika doğrulamalı TLS ve cihaz başına benzersiz şifrelerle kullanıldığında çoğu kurulum için yeterince güvenlidir. 1883 portunda düz TCP üzerinden ise şifre, trafiği yakalayabilen herkes tarafından görülebilir.
MQTT şifreyi şifreler mi?
Hayır. MQTT şifreyi CONNECT içinde ham baytlar olarak gönderir. Şifreleme yalnızca bağlantıyı saran TLS katmanından gelir.
Herkese açık broker'a kullanıcı adı ve şifre ile bağlanabilir miyim?
broker.connectmq.com adresindeki herkese açık test broker'ı, boş olmayan ve benzersiz herhangi bir client ID ile anonim bağlantıları kabul eder. Kimliği doğrulanmış, özel trafik için kendi broker'ınızı oluşturun ve oluşturulan kimlik bilgilerini kullanın.
0x86 ile 0x87 arasındaki fark nedir?
0x86, kullanıcı adının veya şifrenin yanlış olduğu anlamına gelir. 0x87 ise kimlik bilgilerinin anlaşıldığı, ancak istemcinin bağlanmasına veya işlemi yapmasına izin verilmediği anlamına gelir.
