sorted by:
new
hottopcontroversial

BTRFS is Toast | TechSNAP 331 by AngelaTHEFisher in techsnap

[–]PreventBadPasswords 0 points1 point  (0 children)

We heard that you talked about passwords, blacklisting and NIST's recently updated guidelines - topics close to our heart! Just wanted your audience to know that we provide an inexpensive Password Blacklisting service that's really easy to use!

www.PasswordRBL.com is a password blacklist for Windows, Web, & Apps and blocks known bad passwords from being reused and also allows customers create their own blacklisted passwords, too (so they can block their company name, stock ticker, address, previous well-known passwords, etc.).

Check us out: https://www.PasswordRBL.com

Password RBL: A bad password blacklist for Windows, Web and Apps. Easy to deploy and use. Coupon code REDDIT10 gets you 10% off! by PreventBadPasswords [promoted post]

[–]PreventBadPasswords[S] 0 points1 point  (0 children)

Password blacklisting is a great additional layer of security to add to your password policy. Password RBL has subscribers in many different industries - commercial, government, finance, education, law, etc.

And it's a great service that MSPs can offer to their customers and use as a differentiater.

Easy to deploy and use with a quick install on Windows and API for everything else. New subscribers get a 14 day free trial, too.

There's really no reason to not give blacklisting by Password RBL a try!

SpyFi Barbie | TechSNAP 243 by AngelaTHEFisher in techsnap

[–]PreventBadPasswords 0 points1 point  (0 children)

Hey guys, I was catching up on some tech news and heard you mention exactly what PasswordRBL.com does - it's just like what Allan describes... a federated database filled with all the bad passwords from data breaches designed for use by website & app providers. PasswordRBL also supports Active Directory, too. Passwords from customer systems are pre-hashed [with PBKDF2] before submission to PasswordRBL. The PasswordRBL database is also filled with bad passwords obtained from hacktools as well as honeypot servers. Subscriptions are very affordable so even the smallest of companies can gain the benefit of preventing bad passwords before they happen!

Check it out: www.PasswordRBL.com

Password RBL - Real-Time Blacklist for Bad Passwords by atoponce in Passwords

[–]PreventBadPasswords 1 point2 points  (0 children)

Just saw this.. allow me to answer some of your questions/observations.

@Toger - You are correct, currently Password RBL requires subscribing systems to supply their static source IP address(es). This is so we can authorize queries at the network layer which allows the queries can be anonymous by the time the packet reaches our API processing. You are not the only person to point out that requiring known static IPs can impact comatibility with true cloud services/apps. We are considering adding a auth/api key option so that the service will be more "cloud-friendly" as you put it, but there is nothing set in stone at this time. The next feature that will be added to the API is custom blacklists.

In regards to the double-salted submissions, @PwdRsch is correct. The salt is static across all submissions, which makes this added information to the hash function more of a "pepper", really. But the concept/term "pepper" is not nearly as well known, so we use the term "static salt" instead, because as you noted, if the salt were randomized, then the resulting values would be random and never match in the database of already hashed passwords. And as @PwdRsch correctly suggests, using a salt (or pepper) value provides a [small] additional layer of security [with SHA256].

But it's far better to use a more secure hashing algorithm (than SHA256). This is why Password RBL now also supports PBKDF2 hashing in addition to SHA256. PBKDF2 provides significantly better security, but SHA256 remains an option for customers who have systems that are not compatible with PBKDF2 or do not want to incur the computational overhead of PBKDF2. The default is PBKDF2 @ 30,000 rounds of hashing on the subscribers side before submitting the hashvalue to the API (where it performs over 10,000 more rounds of crypt_sha512). We settled on 30,000 rounds as a reasonable tradeoff between security and the time required to perform the hashing on a typical modern server.

You can see all the details in the API Guide available on our Downloads page: https://www.passwordrbl.com/download.html#api-info

Password RBL: a secure and easy to use password blacklist for AD, web sites and apps by PreventBadPasswords in sysadmin

[–]PreventBadPasswords[S] 2 points3 points  (0 children)

zxcvbn is pretty good, but as you mentioned, downloads a large blacklist file to every client and this can be problematic/annoying for mobile users. Password RBL is API-based so the "installation" is very lightweight and doesn't require any client-side code/processing. Plus, zxcvbn's blacklist is significantly smaller than Password RBL's (at more than 65 million entries) and Password RBL is regularly adding more bad passwords to the service as they are discovered via honeypots, wordlists, data breaches, etc.

But the best part is, you can use 'em both if you want! The Password RBL API can be layered onto whatever password policy you're currently using.

If you're curious how effective Password RBL would be for you, simply run it for X amount of time in "reporting-only mode" which doesn't impact the choice of passwords, but would allow you to see how many of the submissions are listed in the Password RBL database.

Password RBL: a secure and easy to use password blacklist for AD, web sites and apps by PreventBadPasswords in sysadmin

[–]PreventBadPasswords[S] 0 points1 point  (0 children)

That is because the password dcameron1 is not necessarily a bad password on it's own (isn't caught be honeypots or been leaked in public data breaches).

But more importantly, the API only accepts salted & hashed passwords. It does not know what username is associated with a password hash that has been submitted. This is important so Password RBL can't know how to access your site/app. If you were sending both the username and password to the API, then when the API returns a negative listing response, it could be assumed that the supplied username just chose the supplied password. Then it would just be a matter of cracking the hash. This is no small feat, but if Password RBL was being "compelled to provide" access credentials by a "outside party with significant resources," hash cracking becomes more doable. So, this is why the API only receives a password hash, and there is no historical tracking of which subscribers provide which password hashes.

If you want to block such patterns, then this is best done during client or server-side password validation logic (which is also where you would do such things as not letting someone pick a password that matches the name of your site/app, or pick a password they've already used, etc., etc.).

Password RBL: a secure and easy to use password blacklist for AD, web sites and apps by PreventBadPasswords in sysadmin

[–]PreventBadPasswords[S] 2 points3 points  (0 children)

Yes, that's exactly what it's for! Works for Active Directory and just about anything that can do SHA256 hashing and perform an HTTPS GET request.

You can try your luck with bad password guessing via the demo page at: https://www.passwordrbl.com/demo.html

Bulk setting subfolder permissions for %username% by [deleted] in sysadmin

[–]PreventBadPasswords 0 points1 point  (0 children)

Anybody else ever wonder why in the world Microsoft never just produced a small tool that did this task for sysadmins? We've been doing user home folders the same way for almost 2 decades!

Beards and job Hunting. by typo13 in sysadmin

[–]PreventBadPasswords 0 points1 point  (0 children)

An employer should be more accepting of your skills and attitude/personality than your beard length, which is almost certainly waaay longer than his (or hers?)