Changes between Initial Version and Version 1 of Ticket #50027, comment 14
- Timestamp:
- 04/29/2020 06:52:51 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #50027, comment 14
initial v1 1 1 thank you @bgermann - I agree with the filters for password rules. I wonder if there is any filters already to validate an incoming password (such as a strength check for passwords when user enters a new password). 2 2 3 @Otto42 - the 72 byte limit is from bc eyot and not PHP itself. regardless of the caller, bcryot will truncate I out to 72 bytes.3 @Otto42 - the 72 byte limit is from bcrypt and not PHP itself. regardless of the caller, bcrypt will truncate I out to 72 bytes. 4 4 5 5 I also always typed 72 "bytes" because that's what matters for bcrypt. For a typical password that's typed on a US keyboard layout (ASCII and a few more Latin characters), the character count is the same as byte count. We will be using UTF-8, which means we will use the least amount of bytes per character (compared to UTF-16 and 32). The upper limit for password length would be between 72 ASCII characters or 18 complex emojis (such country flags, or thumbs up emojos with a specific color. 6 6 7 7 8 as for the portability, I understand the hashes would be a deterministic function. it loses portability as in you cannot use the same password hashes between two different systems. for example, one might have a Laravel application that uses WordPress users table to authenticate users. if we were to impose any pre-processing for the password before it goes through password_hash(), all other systems need to do this now, thus, losing the portability. ideally one would be able to throw in an ORM to WordPress users table and authenticate users.8 as for the portability, I understand the hashes are deterministic functions. It loses portability as in you cannot use the same password hashes between two different systems. for example, one might have a Laravel application that uses WordPress users table to authenticate users; If we were to impose any pre-processing for the password before it goes through password_hash(), all other systems need to do this now, thus, losing the portability. Ideally one would be able to throw in an ORM to WordPress users table and authenticate users.