OpenID Yahoo, Google ve Flickr gibi ortak web hizmetleri mevcut hesaplara dayalı kullanıcıların kimliğini doğrulamak için bir yöntemdir.

Sitenize giriş uzak siteye başarılı bir giriş dayanmaktadır.

Siz duyarlı kullanıcı bilgilerini saklamak veya kullanıcı oturum açma güvenli SSL kullanmak gerekmez.

Kütüphanenin bir PHP'nin sürümünü bulunabilir here.

Ben kullanmak OpenID.

But like stackoverflow I use the Google project openid-selector to do the heavy lifting.
Demo Page here.

(OpenID) belirgin avantajları vardır.

• Bir güvenlik uzmanı olmak gerekmez.
• Kullanıcılar kendi bilgi ile büyük siteler güveniyorum.
• Sen (takma vb) gibi şeyler isteyebilir ama kullanıcı içeri tercih vardır
• You don't need to worry about:
  • kayıt işlemleri
  • kayıp / unutulan şifre

do NOT try to re-invent the wheel - bu durumda bu söyleyerek değer gibi büyük cevaplar bir sürü burada, ama ben hissediyorum! Bu yollar çok çeşitli kullanıcı kimlik doğrulaması kadar vida son derece kolaydır. Eğer really özel bir çözüm gerekiyor ve güvenlik programları ve iyi uygulamaların bir firm bilgiye sahip olmadıkça, hemen hemen kesinlikle güvenlik kusurları olacaktır.

OpenID büyük, veya kendi rulo için gidiyoruz eğer, en azından bir kurulan kütüphane kullanımı ve belgeleri takip edin!

PHPass Bcrypt kullanarak hafif, değişken maliyet şifre karma kütüphanedir.

Değişken maliyet daha sonra sorunsuz bir şekilde önceden karma kullanıcı şifreleri geçersiz kalmadan güvenliğini artırmak için parola karma bir 'maliyet' açmak anlamına gelir.

Nedeniyle değil karma boyutu, ama bunu üretmek için gerekli yineleme sayısını artırarak 'maliyet' artan bile karma depolama için kullanılan alan boyutu sabittir.

Login using HTTP AUTH

1. Apache kullanarak: http://httpd.apache.org/docs/2.2/howto/auth.html
2. Bu IIS ve other web servers ile de mümkündür.

PHP, sadece $_SERVER['PHP_AUTH_USER'] kimlik doğrulama sırasında kullanılan kullanıcı adı almak için kullanmak zorunda için bir kez, doğrulanmış.

Bu daha hızlı olabilir ve bazen, komut seviyesinde işleme çözümü daha esnek bir çözüm kısıtlı bilgiler mevcut yapılan tüm giriş için kullanılan kullanıcı adı gibi kullanıcı ile ilgili gerekli şartıyla.

Ancak, betik dili içinde tam bir HTTP AUTH şemasını (aşağıda açıklandığı gibi) uygulamak sürece HTML forma kimlik entegre unutun.

Rolling your own HTTP AUTH within your scripting language

Aslında extend HTTP Basic Auth ile in komut dosyası dili, onu taklit edebilir. Bunun için tek gereksinim, betik dili HTTP istemci HTTP başlıklarını göndermek mümkün olmasıdır. PHP kullanarak bunu gerçekleştirmek için nasıl bir ayrıntılı bir açıklaması burada bulunabilir: (see more on PHP and HTTP AUTH).

Sen HTTP AUTH'u kullanırken çok daha fazla esneklik sağlayan, yine bazı sadeliğini koruyarak, (bilgi kalıcı olmak için gerekli değilse) tipik bir kimlik doğrulama şeması, dosya saklama, hatta PHP oturumları veya çerezleri kullanarak yukarıdaki makale genişletebilirsiniz.

Downsides to HTTP AUTH

1. HTTP auth için ana dezavantajı çıkıyor olabilir komplikasyonlardır. Kullanıcının oturum temizlemek için ana yolu tarayıcıyı kapatmak, ya da 403 Doğrulama Gerekli olan bir başlık kapalı geçmektir. Ne yazık ki, bu HTTP AUTH açılan sayfaya geri geliyor ve daha sonra iptal tekrar giriş veya vurmak için kullanıcıları gerektirdiği anlamına gelir. Bu dikkate kullanışlılık çekerken iyi çalışmayabilir, ama (durumunu saklamak için tanımlama bilgileri ve HTTP AUTH bir arada kullanarak yani) bazı ilginç sonuçlar etrafında çalışmış olabilir.

2. HTTP AUTH pop-up'lar, oturum ve HTTP başlık taşıma standart tarayıcı uygulanması ile belirlenir. Bu, (diğer alternatifler aksine) geçici çözüm olasılığı olmadan (herhangi bir hata dahil) uygulanması ile sıkışmış olacak demektir.

3. Temel auth da auth_user ve şifre sunucu günlüklerinde göstermek anlamına gelir, ve sonra aksi takdirde kullanıcı adı ve şifre de düz metin olarak her sorgu ağ üzerinden gitmek, çünkü her şey için https kullanmak zorunda.

Onu geri kalanından uygulamanızın güvenlik katmanı ayırmak için önemlidir. Uygulama mantığı ve iletişim sistemi arasında bir mesafe varsa, başka bir yerde güvenli bir yerde güvensiz iletişim ve ücretsizdir. Belki bir hata yaparsanız ve şifrelenmemiş bir çerez bir parola göndermek, ya da belki bir adım için kullanıcının kimlik bilgilerini doğrulamak için unutacaksınız edeceğiz. Kullanıcı ile iletişim için bir 'doğru yolu' olmadan, bir hata yapmak için emin olabilirsiniz.

Örneğin, bu artık kullanıcıları doğrulamak nasıl diyelim:

user_cookie = getSecureCookie()
if (user_cookie.password == session_user.password) {
    do_secure_thing()
    ...
}

Bir güvenlik açığı getSecureCookie () keşfedilen ve size uygulama boyunca kullanıcıları doğrulamak için bu kodu kullanabilirsiniz ise, sabit gereken getSecureCookie (tüm örneklerini) bulmak olmayabilir. Ancak, eğer, sizin güvenlik sizin mantığı ayrı:

if (userVerified()) {
    do_secure_thing()
    ...
}

... Hızlı ve kolay bir uygulama yeniden sağlamak için mümkün olacaktır. Kendinize güvenlik yapmak için bir 'doğru yolu' vermek, ve çok daha az olasılıkla büyük bir güvenlik gaf yapmak olacaktır.

İyi kimlik çok faktörlü kimlik doğrulama, tüm güvenlik hassas günlük-ons üzerinde ideal bir belirteç az sürümünü kullanmaktır.

Şifre korumalı ve yüksek güvenilirlik ve güvenlik ile kullanımı daha kolay. EMC / RSA ötesinde mevcut çeşitli vardır. Ben SwivelSecure en PINSafe tercih ederim.

Igor S