Aizmirsi paroli fīča

[xPtv45z]

Esi pārliecināts, ka šie abi iet kopā? :)

5. mainot paroli, ja jaunās ievadītās paroles sakrīt, parāda OK msg, apdeito attiecīgajam userim paroli uz jauno un te gribētu dzēst visus ierakstus "forgot_password" tabulā, kuros fito konkrētā deguna user ID.

 

Darbosies arī validācija uz to, ka deguns var 1x 24 stundās tikai pieprasīt jaunu paroli. To čekos pēc pēdējā ieraksta "forgot_password" tabulā (laiku rēķinot pēc date_created).

[senters]

xPtv45z, jā, pēc veiksmīgas paroles nomaiņas izdzēš pilnīgi visus ierakstus no tabulas, kur figurē konkrētā lietotāja ID. Jo nav jau nekur teikts ka viņš pēc vienas veiksmīgas paroles nomaiņas uzreiz to neaizmirsīs nākamajā stundā.

 

Te bija doma, ka neļaut pieprasīt paroles nomaiņu, to līdz galam neaktivizējot. Ja iziet pilnu ciklu (nomaina paroli) tad vari kau katru stundu mainīt paroles. Es tā biju iedomājies.

[senters]

daGrevis, "deguni" rakstot domāju purni/sejas/cilvēki, nekādas dziļās domas nav.

[Aleksejs]

Iesaku iepazīties ar š;o dokumentu, lai pārliecinātos, ka kaut kas no tur minētā nav palaists garām:

Security Patterns Repository Version 1.0 PDF

Skatīties sadaļu par Account Reset un tur pieminētajiem papildpatterniem.

 

Šī StackOverflow diskusija ir atzīta par labu esam:

The Definitive Guide To Website Authentication

 

Šis "manifests" arī satur kodolīgus uzstādījumus:

Secure Web Application Framework Manifesto – Draft

3.2.5 SECURE PASSWORD RESET / CHANGE

Insecure forgotten password mechanisms are one of the easiest ways for attackers to break into an application. In particular, forgotten password questions are often easy to answer and are susceptible to brute forcing. If a secure web application framework provides password reset functionality, it should use the following sequence or one that provides a similar level of security:

* Users visit a password reset page where they submit their User ID or email address. The page should also include an anti-automation technique, such as a CAPTCHA image with accessibility options for visually impaired users, to prevent user enumeration

* Upon form submission, the site displays a page indicating that an email with instructions was sent to the user

* In the interim, the site should send an email with a temporary link to the user. The link should expire after a short period of time (e.g. 1 hour)

* When the user clicks on the link, they should be taken to a page where they respond to pre-determined forgotten passwords

* The application should enforce account lockout if the user fails to correctly answer a question after a configurable number of tries (e.g. five wrong answers)

* Users should be informed via email that their password has been changed, but the password itself should never be sent via email

For cases where a user wants to change their password after successfully authenticating, ensure that the user enters both the old password and new password prior to changing. This is particularly important in web applications due to the risk of Cross Site Request Forgery on password reset pages.

[Faks]

ja godigi bcrypt ir lens bet sha512 ar salt ir nemazak slikts :) tas ir manas domas plus neskaitamas reizes atraks :)

[briedis]

ja godigi bcrypt ir lens bet sha512 ar salt ir nemazak slikts :) tas ir manas domas plus neskaitamas reizes atraks :)

 

Tur jau tā lieta, ka, jo lēnāks, jo labāk.

[Grey_Wolf]

Lai būtu grūtāk proles uzlauzt, uzliec tā ka nākamais mēģinājums var būt tikai pēc pāris sekundēm.

Vienkarši , kodam būs problemātiski to paroli lauzt, piedevām var uzlikt lai laiks mainās teiksim no

0-10 sek ..

pirmos trīs mēģinājumus, var arī ar 0 laiku, katru nākamo palielinot par 1 sek. un ierobežojot meģinājumu skaitu ( dienā)

[mad182]

Grey_Wolf: nav jau īsti runa par brute force uzbrukumu pašai web lapai. Tur jebkurā gadījumā tāds ātrums nesanāks.

Edited December 10, 2011 by mad182

[daGrevis]

ja godigi bcrypt ir lens bet sha512 ar salt ir nemazak slikts :) tas ir manas domas plus neskaitamas reizes atraks :)

 

He, he.