PBKDF2/RFC2898/PKCS#5 modes?
As a less immediate, longer term project, I'd like to request generic PBKDF2 (also known as RFC2898 and PKCS#5) support, in whichever applications can reasonably support it. For hash algorithms, I'd say SHA1, SHA256, and SHA512 are the top three in use (with SHA1 winning by a large margin). As we already have WPA support (which I believe is, for the PMK derivation, PBKDF2(passphrase, ssid, 4096, 256[bits])), the algorithm structure has already been coded.

Note that one new feature for the general case would be pulling in either four or five parameters, instead of our previous 1 or 2:
1 - Passphrase
2 - salt
3 - number of iterations
4 - length in bits or bytes of the derived key (output)
5 - HMAC to be used

Anyone crafting a modern, well secured password storage system is likely using PBKDF2, scrypt, or bcrypt (per https://www.owasp.org/index.php/Password...heat_Sheet). These systems need to be audited just like any other system, to see who chose "P@$$w0rd123" as their password.

Microsoft's .NET implementation is SHA1 only (http://msdn.microsoft.com/en-us/library/...bytes.aspx).

BouncyCastle has both .NET and Java implementations, handling more HMAC choices (http://www.bouncycastle.org/)

Perl has Crypt:TongueBKDF2 (http://search.cpan.org/~arodland/Crypt-P.../PBKDF2.pm), which handles more HMAC choices.

Very official PBKDF2 HMAC-SHA1 test vectors are in RFC6070 (http://tools.ietf.org/html/rfc6070).
any example app/system that actually uses this?
Aside from some applications following the OWASP Password Storage Cheat Sheet:
Django web framework
"Django will use the first password “hasher” that you provide it (at least 1 must be included within your settings.py file.

'django.contrib.auth.hashers.SHA1PasswordHasher', # Insecure Hashes
'django.contrib.auth.hashers.MD5PasswordHasher', # Insecure Hashes
'django.contrib.auth.hashers.CryptPasswordHasher', # Insecure Hashes

"When initialized with a passphrase SQLCipher derives the key data using PBKDF2 (OpenSSL’s PKCS5_PBKDF2_HMAC_SHA1). Each database is initialized with a unique random salt in the first 16 bytes of the file. This salt is used for key derivation and it ensures that even if two databases are created using the same password, they will not have the same encryption key. The default configuration uses 4000 iterations for key derivation (this can be changed at runtime using “PRAGMA kdf_iter”)."
The opensource Cryptsharp (https://github.com/ChrisMcKee/cryptsharp) from @chrismckee (twitter) provides PBKDF2/bcrypt/scrypt for .NET.

I'm tempted to say this is one example of what EpiServer could have used (or recommended people to use), instead of the default SHA-1, as found earlier this year and supported by hashcat*

Should make it easier to come up with Microsoft based systems and code/hash/salt examples I guess, so that it might get supported?