Old practice 2.32 wanted you to make sure administrative interfaces weren’t accessible to untrusted networks. This may have been removed because it becomes more difficult in a cloud-hosted world, or maybe because some apps use the same login interface for admins and normal users. Finally, gone is the old 2.18 requirement to verify that username enumeration isn’t possible in login or account recovery functions. While preventing account enumeration is good, it tends to provide little value at the expense of the user experience: security.stackexchange.com/questions/6266…

OWASP released v4.0 of the Application Security Verification Standard (ASVS) in March, listing security practices for orgs to design, code, and test apps against. github.com/OWASP/ASVS There was substantial content change in the authentication section, so I'll comment on it. They state in the V2 Authentication Verification Requirements section that their goal is bringing this standard closer in line with significant authentication changes published by NIST in the SP 800-63 Digital Identity Guidelines update that came out after ASVS v3.0.

Presentation: Leveraging Users' Engagement to Improve Account Security, by Amine Kamel (@dontlivetwice), Head of Security at Pinterest. Pinterest pulls in leaked password data from providers or pastes and finds email addresses that match their users. Then the leaked plaintext passwords are hashed and compared to their user hashes. Any matches and they tag the account as a high risk user (HRU).

Researchers asked 43 freelance developers to code the user registration for a web app and assessed how they implemented password storage. 26 devs initially chose to leave passwords as plaintext. [PDF] net.cs.uni-bonn.de/fileadmin/user… Those devs were then asked to rewrite their code to 'store passwords securely.' Overall here are the methods of password storage chosen by the developers:
8 - Base64
3 - AES
3 - 3DES
10 - MD5
1 - SHA-1
5 - SHA-256
5 - PBKDF2
7 - Bcrypt
1 - HMAC/SHA1