E-posta onay kodları için en iyi uygulamalar

5 Cevap php

Ben kaydolarak kullanıcıları içeren bir PHP web sitesi oluşturma, ve ben "e-posta onay" kodları için en iyi uygulamalar hakkında merak ediyorum.

Yeni kullanıcılar e-posta adreslerini onaylamanız gerekir - Ben bir kod üretme ve o da onun hesabını etkinleştirmek için kullanabileceğiniz bir e-posta kullanıcı göndererek bunu. Aksine bir veritabanında bu anahtarı depolamak yerine, ben kullanışlı küçük bir geçici çözüm kullanıyorum: kod sonucudur:

md5("xxxxxxxxx".$username."xxxxxxxxxxx".$timestamp."xxxxxxxxx");

$ Timestamp kullanıcı oluşturma zamanı ifade eder nerede. Bütün ben bu konuda oldukça memnun oldu, ama sonra düşünmeye başladım, bu yeterince güvenli? Ve ne çarpışma olasılığı hakkında? Ve ben de bir çarpışma yanlışlıkla başka bir kullanıcının parolasını sıfırlamanın bir kullanıcı neden olabilir, ben de benzer bir metodoloji kullandıysanız parola sıfırlama, vb kodları oluşturmak gerekir. Ve bu hiç iyi değil.

Yani bu şeyleri nasıl yaparsınız? Düşüncelerim aşağıdaki biçimde bir tablo oldu:

codePK (int, a-I), userID (int), type (int), code (varchar 32), date (timestamp)

'Tip' 1, 2 veya 3 anlam "aktivasyon", "e-posta değişim" veya "şifre sıfırlama" nerede olacağını. Bu bunu yapmanın iyi bir yolu var mı? Daha iyi bir yol var mı?

Yukarıda benzer bir yöntem kullanarak, otomatik olarak cron işleri kullanmadan iki gün boyunca eski şey silebilir? Benim ev sahibi (nearlyfreespeech.net) bunları desteklemiyor. Mümkünse ben = P. sadece dağınık olduğu gibi, şeyleri siler bir script var wget harici ana bilgisayara bir cron işi zorunda kalmamak istiyorum

Thanks!
Mala

Update:
To clarify: I've realized the only way to securely and safely go about this task is by using a database, which is what the original function was trying to avoid. My question is on how the table (or tables?) should be structured. Somebody suggested I do away with codePK and just make the code a PK. So in short, my question is: is this what you do?

5 Cevap

Ben hileler bu tür ihtiyacınız olduğunda sizin tarafınızdan belirtilen, hem normalde iki nedenden biri olan:

  1. Doğrulama e-postalar için kullanılan bir anahtar kullanıcıya gönderdi
  2. Parola sıfırlama bağlantılar için kullanılan bir anahtar olarak

Tabii ki böyle bir yapıyı kullanarak düşünün sayısız başka durumlar da olacaktır.

Her şeyden önce, her zaman gizli ve sadece bildiğiniz tuz çeşit kullanmalısınız. Bu tuz her kullanıcı için farklı olması gerektiğini unutmayın. Tuz, örneğin, sha256(something random) şeklinde hesaplanabilir. Bu tuz daha sonra (tuz ile karma) kullanıcı adı ve şifre ile birlikte veritabanında saklanmalıdır.

Ne şifre sıfırlama linki gönderirken yapacağını başka tuza (sizin tuz ile karma bir şey kullanıcı erişimi vermeyin. O yüzden potansiyel tuzunu anlayamadı BruteForce kullanarak, şifresini bilir) oluşturmaktır. Aslında rastgele bir dize yalnızca bir karma (Eğer uzunluğu bir sorun olduğunu belirttiğim gibi, burada md5 gitmek isteyebilirsin) olduğu, diğer tuz, daha sonra veritabanına kaydetmeniz gerekir.

Genellikle sadece kullanıcıların tabloya ek bir sütun ekleme ile uzak alabilirsiniz. Bu, ancak, aynı zamanda parola sıfırlama olmuştur veya kullanıcı aktive edildikten sonra, çoğu satırlar sırayla diğer bazı sorun getiriyor null değerleri, sahip sonuçlanır veritabanından anahtarı, kaldıracak ağırlıklı olduğunu, birkaç sorunu var .

: Bu aslında aşağı kaynar ne

  • Benzersiz bir-için-kullanıcıya tuzu (and belki de bir küresel, gizli tuz) kullanarak kullanıcıların şifrelerini hash.
  • Eğer gerçekten rastgele şeyler isterseniz damgaları, mt_rand() hatta random.org gibi rastgele veya pseudorandom kaynaklarının bir dizi karma bir anahtarı oluşturun.
  • Global tuz veya kullanıcı vs parola sıfırlama tuşları, etkinleştirme anahtarları da dahil olmak üzere, erişim alır şey karma için kullanıcıya özgü tuz asla kullanmayın

Ben hiçbir şekilde bir güvenlik uzmanı tarafından ve ben muhtemelen şeylerin bir dizi unutmuş, ve bazı çok kötü bir uygulama şeyler söz olabilir değil lütfen. Sadece benim 5 kuruş ;-)

Bu doğru Eğer internette yöntemi yayınlanan noktaya kadar yeterince güvenli oldu! Eğer iyi bir fikir değil bilinmezlik tarafından güvenlik güvenerek çünkü bu.

Sadece sizin için bilinen bir gizli anahtar içeriyor, hangi ideal anahtarlı hash fonksiyonu veya MAC çeşit kullanmak gerek.

Neden yetkilendirme anahtarı için temel olarak kullanıcı herhangi bir veri kullanabilir?

Ben bunu neden sadece basit rastgele bir anahtar bir ek kayıt (bazı ek manipülasyon ile belki bir md5'ed uniqid) ekleyebilir ve ardından karşı kontrol değil, bir veritabanında de-aktif veri depolamak tahmin o?

Neden kodu alan benzersiz dizin yapmak değil mi? Yani collsisions asla olacak?

Also, if you don't need to create hash from user input and match it to database hash (email confirmation, password reset etc) - you can add random string to the hash body, like md5('xxx'.$username.'xxx'.time().'xxx'.rand())

Neden böylece çarpışma ile herhangi bir sorunu ortadan kaldırarak, kendi kullanıcı adı and kendi kod girmek için kullanıcı sormuyorsun? Eğer hala e-posta almak istiyorum anahtar soruyorsun gibi güvenlik açısından hiçbir şey kaybetmezsiniz, ama onları diğer kullanıcıların şifrelerini sıfırlamak için güçlü olmak durdurmak istiyorum.

etiketler