Jfreegman

Wikipedia is anything but neutral on political topics. Their political bias comes straight from the top with corrupt administration and disproportionate application of their own rules and guidelines. I suggest you watch this interview with Wikipedia co-founder Larry Sanger on why you shouldn't trust Wikipedia. https://www.youtube.com/watch?v=l0P4Cf0UCwU

There have been 6 releases in the past year, including a major feature merge.

https://github.com/TokTok/c-toxcore/releases

https://github.com/TokTok/c-toxcore/pull/2269

Tox is developed entirely by unpaid volunteers which means it will have periods of prolonged inactivity, but it's certainly not dead.

At the time I read it, I found myself hating the book and its characters, yet unable to put it down. It wasn't until long after I had finished the book that I realized that there were no novels that had ever made me actually feel such strong emotions before, and that's precisely what makes it a masterpiece. I ended up reading the rest of his major works, and to this day I don't think any other author I've read can compare in terms of getting inside your head.

>Every password that becomes public knowledge ends up in credential stuffing lists, whether it matches your password policy or not.

That's right. And we don't want to produce passwords that are likely to be on those lists. A simple policy greatly reduces the chances of that happening. After a certain number of zeros, entropy is no longer a concern.

>"Common patterns" and "passwords that contain repeated characters" are not even remotely the same thing.

I've already addressed this.

Why doesn't it? If that password became public knowledge, then it certainly does exist in lists and tables. Its high entropy is only protective as long as it remains secret. This is why it's important to avoid common patterns, even if those patterns are a result of a random number generator.

You missed my point again, and your tangent on randomness is unnecessary; I have no misconceptions of how randomness works, and it is precisely that understanding that has lead me to these decisions - a pure random password generator produces every word in the English language. That's not a good thing!

The point remains that if your password generator produces passwords such as "aaaaaaa" then it is a bad algorithm, end of discussion. It doesn't matter if the passwords it produces are completely random. That's not the goal and is completely irrelevant. The goal is to produce unique, unpredictable passwords that utilize randomness. We're not producing fixed-length keys. In the average case for web-based logins, uniqueness is far more important than entropy.

So, I'll say it once more. If you can demonstrate how passwords generated by the algorithm I wrote are predictable or otherwise insecure in a real-world setting as you claim, then do it. If you cannot, then any further responses are in vain.

>No

Yes. For example, if a rainbow table contains a match for "a" repeating 500 times, then that password's entropy is a non-factor. Therefore entropy in of itself does not necessarily mitigate rainbow table attacks. Entropy does necessarily mitigate naive brute force attacks. We can use this same logic for more reasonably sized passwords that are comprised of known patterns but would otherwise be difficult to brute force.

Obviously you could use extremely long passwords and be fairly certain that you won't end up with something that would be found in a rainbow table or dictionary. You could also just use passwords that are long enough that they can't be brute forced and remove common patterns from the set of possible passwords. Both of these solutions are valid, and both have theoretical weaknesses that are irrelevant in practice.

You've spent a significant amount of time trying to convince me that my random password generator is flawed in some way. Why don't you just demonstrate how instead of continuously trying to argue tangentially related theoretical points? I would hope that such an effort would be motivated by a practical concern and not merely the desire to bikeshed out of boredom.

Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks, hence the distinction. If every user had a unique password, rainbow tables would be rendered useless. This is why it's important to reduce the likelihood that a randomly generated password is comprised of a common pattern.

>But you can, apparently, force them to use passwords that meet whatever other weird criteria you choose.

No one is forced to use the random password generator, and even if I set a minimum limit they could just chop it up to their liking. All I can do is guide users towards a criteria I think provides the most effective security.

>You've decided by policy to allow "agkxA1"† but not "V+0mCx&3LmgyC" (because the latter has a "duplicate letter C") and that's crazy.

I didn't suggest that all passwords that contain duplicate characters are weak. But if we were to simply use a random string of characters without discrimination, then we would have to allow passwords like "aaaaaaa" and "abcdefg123", which is unacceptable in my opinion. If you agree that there should be some sort of policy that guarantees certain properties, then I'm confused by your position, as that would contradict the main point of your criticism centered around code complexity.

The list of attack vectors was not to suggest that removing duplicate characters was a solution to all of them (I disagree with your assessment but we'll leave that alone for now). I was merely highlighting the fact that brute force attacks are one of the least important factors in securing web-based accounts.

If you are able to point out a concrete example of a vulnerability introduced by disallowing duplicate characters (that includes bugs in the code caused by the added complexity) I'm all ears/eyes. If not, I'm going to call an end to this debate for now. I do appreciate your input though and it's definitely given me something to think about.

Small correction: the password that has been seen 12 times is "aaaaA1" (no ! char). But "agkxA1" has still been seen 0 times.

>If you use passwords of a small enough size that this would really be a problem (like four digit PINs or your "aaaaA1!" example) then your password isn't delivering adequate security against brute force and so you've definitely lost.

I can't force users to use reasonably long passwords. In the case that they don't (and some certainly won't), it's preferable that their password is still as good as it can be given the length.

When it comes to web logins, brute force is probably the least effective method of attack. Social engineering, dictionary attacks, rainbow tables, password lists, guessing and so on are all much bigger concerns. It's my thinking that most of those threats are better addressed by sacrificing a negligible amount of entropy and removing a large subset of weak passwords.

Moreover, this reduction in entropy only applies when the attacker knows the algorithm used to derive the password, making it even less relevant for the average case. (That's not an appeal to security through obscurity; just an observation).

>Whereas if you generate passwords of decent length and at random then they're random so there's no purpose in checking them.

Random != secure. "aaaaaaaaaa" could be the result of a random function. The goal is to create passwords that are both difficult to brute force, and difficult to guess, while making no assumptions about the length.

Entropy has diminishing returns; if it takes 10 million years to crack a password, another 5 million doesn't increase security. However I would re-consider if someone could provide a concrete example of how the small loss in entropy could lead to a practical vulnerability.

I agree that there are risks either way, though like you said, the threat model is a bit different. SpicyPass isn't explicitly for web passwords. It's just a generalized key value store with added security. I use it to store my bitcoin keys for example, and that's probably not something you want to expose to the cloud and/or your browser.

With that said I don't rule anything out for the future.

That's a great question, and I wish I was good enough at math to give you a sophisticated answer. But my thinking is that the entropy you might gain by allowing duplicates is negated by the huge set of weak/guessable passwords you allow. For example, the password "aaaaA1!" is probably more likely to be guessed or used by others than "agkxA1!". (I just checked on haveibeenpwned.com, and the former has been seen 12 times, while the latter has been seen 0 times. Not very scientific I know)

Though this isn't set in stone if someone wants to formally correct me.

And libsodium is indeed a pleasure to work with.

The pass source code you linked to is just a wrapper for the unix toolset (and has twice the byte count, not that it matters). Pass has a completely different crypto implementation and security model than SpicyPass. The two are not synonymous, either in features or UX. I elaborated on more of the differences between the two in a different reply to a similar comment.

tl;dr different strokes for different folks. I didn't write spicypass with the intent of replacing pass.

Although that sentence refers to the interface and feature-set, not the language on which it's built, I do tend to avoid the more complex features of C++. Is there anything in particular that you find confusing or complex about the code itself?

Third party browser extensions (and cloud syncing) are two things that, while convenient, create potential security holes. I opted for security over convenience with spicypass.

I absolutely understand why this might turn some people off, maybe even most people. But I know that there are people (like me) who want something that isn't connected to the cloud, and isn't going to inherit all of the security flaws of their browser.

Often it just comes down to personal preference. A necessary feature to one person is bloat to another. Git integration for example is not something that meets my criteria for a necessary feature of a password store (think non-developers), although I can certainly understand why some people might love it.

According to the libsodium docs:

>The string produced by crypto_pwhash_str() already includes an algorithm identifier, as well as all the parameters (including the automatically generated salt) that have been used to hash the password.

https://libsodium.gitbook.io/doc/password_hashing/default_ph...

My motivation for writing spicypass was actually a frustrating struggle I once had trying to get pass to play nicely with my GPG installation. I decided it would be easier (and more fun) to write my own.

So one of the main differences is that spicypass is setup-free. You just pick a master password and go. It achieves this by using symmetric encryption via the libsodium library. A nice side-effect of this is that backups are as simple as copying the .spicypass file to your backup device/server. With asymmetric encryption you have to worry about backing up your private keys in addition to the store file(s).

Another major difference is that it has an idle lock. Even if someone has root access to your machine and you leave it unattended while spicypass is running, they won't be able to see your passwords (assuming there's no keylogger involved).

There's also the minimalist aspect. pass has a lot of features that I personally don't need and consider to be bloat. I designed spicypass to my own personal specs: A very simple notepad-like interface, but secure. I figure I can't be the only one who thinks all the bells and whistles that most password managers have just get in the way.

Far from having comparable resources to billion dollar space and nuclear corporations, FOSS developers often have no funding at all and work entirely in our spare time, for free. Any attempt to accomplish "provably correct" code with the same attention to detail that goes into space or nuclear systems would kill a typical FOSS project before a single line of code ever got written.

Astonex was never banned from any of the public tox IRC channels. He was banned from an invite-only channel for off-topic discussion because he was trolling. The ban did not last very long either, because most of us still like him despite his attempts to create drama. Everyone has their off days.

Also, current benchmarks show Rust to be about ~3x slower than C, making it more comparable to Go or Java.

uTox was not originally written by the main toxcore dev. However he and a few other brave volunteers have made a big effort to clean up uTox's code over the past few months. That's why this thread was created now and not 6 months ago.

That last comment was by irungentoo, who is the lead Tox dev and the one who wrote the parsing code.

I should point out that silentbits is not a Tox dev. He was only expressing his personal opinion on that matter.

His last activity on github was 5 hours ago...

Currently no, but there is a groupchat rewrite underway and that is one of the planned improvements.

Toxic is just one of many clients that are built ontop of Tox. Some clients fill a niche, others (like qTox) are meant for widespread adoption.

That's partially true. However if you force TCP connections (in Toxic this is done with the -t flag) your IP is effectively hidden from your contacts because all your traffic gets relayed by TCP nodes in the network. The downside is that forced TCP connections are slower and less reliable.

Though to be properly anonymous you would need to run it through Tor: https://wiki.tox.im/Tox_over_Tor_(ToT)

The reason Tox doesn't have built in anonymity is because strong anonymity has a massive impact on quality (especially streaming data like audio/video). Our goal is to steal normal (non-paranoid) users from Skype and get everyone and their mother using strong encryption. In order to achieve that we need to have comparable quality rather than something that feels like you're using a 28.8k modem.

And again, anyone who actually wants anonymity still has that option.

Unfortunately, being affiliated with 4chan means we attract a lot of trolls pretending to be "ex-devs" or "concerned members of the community" who have nothing better to do with their time than to spread FUD (https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt). We certainly aren't perfect, and have made our fair share of mistakes, but at the end of the day this is just personal drama that serves to distract from the software.