251–260 of 526 posts
Earlier quoted context omitted.
I have a Nokia 1020 Windows Phone. There is a Duo app for it, but it's single account. Duo hasn't updated their WP app since 2012.
I also have a Windows Phone. There's an official Microsoft 2FA app that I use instead of Google Authenticator or Duo, including now for multiple Slack accounts. http://www.windowsphone.com/en-us/store/app/authenticator/e7...
Earlier quoted context omitted.
so the downsides are "it's not maintanable" and "don't roll your own crypto". I think they are negligible compared to the upsides.
The fact that the pepper can't be changed/rotated far outweighs any upsides
scrypt(scrypt(scrypt(scrypt(password, salt), pepper2013), pepper2014), pepper2015)
Earlier quoted context omitted.
Excuse my ignorance, but you probably shouldn't be able to reverse an irreversible hash.
The pepper is being used as an encryption key in that example rather than using hashing.
But, the original example is hashing the password. No encryption involved. So what makes anyone think that they can reverse a hash?
Earlier quoted context omitted.
That's because you're conflating "rounds" with "work factor". "Work factor" is actually 2^rounds, you're using 65536 rounds. Try 4.
Thank you for pointing that out. I suspect many of us in this thread are referring simply to the single parameter to BCrypt.gensalt as the "work factor" or "number of rounds" interchangeably. And you're right, the work factor is what is actually provided to gensalt. Nevertheless, in all implementations I am aware of, the default for that parameter is 10. And earlier, you wrote: > If they used ten rounds, it's dire, a…
I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…
Is there any significant evidence that peppering passwords helps? I've seen arguments for and against peppering out on the big bad internet. Everyone has opinions but there are few people's opinions about crypto that I actually trust. The best article I've seen against this technique is by ircmaxell [0]. Nicely summed up in this sentence "It is far better to use standard, proven algorithms then to create your own to…
Yes, many times a dedicated attacker who has read access to your database will also have read access to your source code or config files, but many times they won't. And if they don't, then they won't be able to crack a single one of your passwords, while even with a modern and proper hashing algorithm they still may be able to crack passwords.
Take the scenario of a relatively intelligent hacking or hacktivist group, of which there've been several in the past 5 years. Let's say they're targeting someone they dislike for whatever reason, and find out that person is registered on some forum and decide to compromise the forum. (This tactic of lifting a whole haystack to find a single needle is very common for motivated attackers.) They don't care about any of the other users, they just want to try and crack the hash of one single member and have a full GPU cluster with which to do it. They're also willing to spend weeks trying to crack that one hash.
If the user's password isn't particularly strong, it's going to fall no matter what algorithm they used.
But if the forum is peppering all of their hashes, and those same attackers can only manage to gain access to the forum's database and not its local filesystem, then their chance of cracking that password goes to 0.
This scenario is a bit contrived because odds are motivated and intelligent attackers like these will end up gaining access to the filesystem and reading the pepper with enough time and effort, but the pepper is still an additional defense and means SQL injection alone won't be enough to crack passwords.
Earlier quoted context omitted.
Excuse my ignorance, but you probably shouldn't be able to reverse an irreversible hash.
It's reversing the encryption, not the hash.
Host your own IRC if you care about the privacy and security of your communication. There is no reason why you can't take 10min to setup a IRC with SSL on your own. Yes, Slack is awesome, lots of features, but it's not yours!
I've run internal IRC and XMPP servers before, and they do one client admirably, but multiple presences for the same user rapidly becomes problematic.
Dear All - Your passwords should be considered compromised. Hashing is merely a deterrent, it does not prevent cracking.
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=703252...
Earlier quoted context omitted.
I agree, but can't deny self-hosted means your security lapses see less fanfare, which has value to the biggest and most lumberingest risk-adverse organizations
not to mention: you can host a chat server in your company network, somewhat protected from random people on the internet, and your ops people should already be securing that from external intrusions anyway.
1. VPNs are almost always terrible for security because people tend to get them for one need (i.e. email, one line of business app, etc.) but when their computer gets compromised the attacker now has access to the superset of everything which every VPN user has ever needed to access and in all likelihood a bunch of other things which were never intended to be exposed but were never adequately firewalled internally.
I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…