My free & secure BNC - resolves to dystopian.world reddit / irc ---------------------------------------------------------------------- benderunit9000 · 2015-03-25 21:23 I see you just successfully updated to znc v 1.6.6.1 any way to donate other than bitcoin? ---------------------------------------------------------------------- glassarrows · 2015-03-25 21:35 ZNC is currently on version 1.6.1, we started our modified ZNC on 1.0 :) We've pretty much completely recoded the backend to make it as secure as possible. If you'd like to donate, that would be amazing, because we haven't gotten a single donation despite having an outrageous number of users. I could figure something out with paypal if you'd like ---------------------------------------------------------------------- benderunit9000 · 2015-03-25 21:38 > I could figure something out with paypal if you'd like definitely interested ---------------------------------------------------------------------- [deleted] · 2015-03-25 21:53 [deleted] ---------------------------------------------------------------------- 0xBADFEED · 2015-04-06 06:48 I like the idea, but saw a few problems: * Your nginx version (1.4.6) is too old, the latest stable release is 1.6.5 and latest mainline is 1.7.11 * Your SSL/TLS config allows for SSLv3 and has no HSTS header. See [sslabs score ](https://www.ssllabs.com/ssltest/analyze.html?d=dystopian.world) * Your registration page has mixed content warning: > Mixed Content: The page at 'https://dystopian.world/register.php' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://dystopian.world:8080/dys/login'. This endpoint should be made available over a secure connection. * Cookies do not have `httpOnly` attribute which means I can access them via non http/http(s) ways: example: in javascript console via `document.cookie`. They also do not have a `Secure` attribute which tells browsers to restrict them to https only. * Moreover your backend is exposed, and ideally it should not be. A better approach is to code up a thin layer where users can enter the settings and which are then relayed (internally) to the webadmin. * The registration page didn't like my 50 digit long randomly generated password (5 digits, 5 special characters, upper and lowercase letters) Also, how are the passwords stored? Which KDF is used and how many iterations? Hopefully you can iterate and keep the service. ---------------------------------------------------------------------- glassarrows · 2015-04-06 22:39 > Your nginx version (1.4.6) is too old, the latest stable release is 1.6.5 and latest mainline is 1.7.11 1.4.6 is perfectly secure. >SSLv3 Didn't notice that, just disabled. >HSTS Not a problem because you can't initiate an insecure connection. >webadmin non-https There we go, fixed >Moreover your backend is exposed, and ideally it should not be. A better approach is to code up a thin layer where users can enter the settings and which are then relayed (internally) to the webadmin. That really doesn't make sense, it would unnecessarily complicate things and create more vulnerabilities than it could potentially solve (which is none that are known - ZNC is open source and has many thousands of manhours pumped into it). The webadmin is perfectly secure as-is. >How are passwords stored? Encrypted in RAM. Never touches the disk. It would compromise the security of the server to tell you why that's important. Security through obscurity is necessary when it concerns physical data theft prevention. >KDF 2 [There you go](https://www.ssllabs.com/ssltest/analyze.html?d=dystopian.world) ---------------------------------------------------------------------- 0xBADFEED · 2015-04-07 00:16 > 1.4.6 is perfectly secure. Did you even bother to take a look at the [nginx changelog/CVE's?](http://nginx.org/en/security_advisories.html). It lists two **major** vulnerabilities that affects 1.4.6. And it's not like it hard to upgrade nginx, whether you are getting it from your distro repo or compiling from source. > Not a problem because you can't initiate an insecure connection. Not true, currently there is a 3xx redirect for `http` -> `https`. This still leaves a door open for MitM and ssl striping (See Moxie Marlinspike's Blackhat/DEFCON talk). With the HSTS header, the browser will refuse to connect on anything but `https`. > The webadmin is perfectly secure as-is. But it wasn't secure. You were serving webadmin over port 8080 exposed to the world, and passwords were being sent in the clear. > Encrypted in RAM. Never touches the disk. It would compromise the security of the server to tell you why that's important. I highly doubt it. Touching the disk is not a security issue. Moreover if the passwords are stored in RAM, what happens when AWS reboots your instance? Yeah, you lose all your user data. More over **passwords should never be encrypted**, because it is a reversible function. The encryption key is stored on the same server which means when your server gets owned the encryption key is mostly moot and, the passwords get leaked. [Read up on Adobe's blunder](https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a- password-disaster-adobes-giant-sized-cryptographic-blunder/). **Passwords, therefore need to be hashed and salted**, since hashing is a one way function. In particular you should use something like bcrypt/scrypt/pkbdf2, with high enough iterations to make it computationally expensive to brute force the hashes. And the password is salted to prevent against [rainbow table attacks.](https://en.wikipedia.org/wiki/Rainbow_table) This is disconcerting, since this is very very basic knowledge, and I don't want to come across as rude (really I am trying to be helpful), but you need to own up to your lack of knowledge/experience and learn, before you make the kind of promises that are made on the homepage. > Security through obscurity is necessary when it concerns physical data theft prevention. Good security doesn't work that way. [Kerchoff's Principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle) Also, your cookies are still accessible via javascript, add `httpOnly` and `Secure` attributes to it. ---------------------------------------------------------------------- glassarrows · 2015-04-07 00:29 >Did you even bother to take a look at the Yes, and I patched them manually. >Not true, currently there is a 3xx redirect for ... ssl striping you misunderstood me, there is already an HSTS header >But it wasn't secure. You were serving webadmin over port 8080 exposed to the world, and passwords were being sent in the clear. MITM is not my highest priority issue. However, you are right, I should've moved it to SSL sooner. >More over passwords should never be encrypted, Slow down, they're encrypted **and** hashed. That should go without saying. >I highly doubt it. Touching the disk is not a security issue. It is when the government attempts to seize your data. Best they can do in this case is preserve RAM, and have a bunch of garbage data with no decryption key. Which brings us to... >Good security doesn't work that way. It absolutely does when you're implementing measures to prevent physical access to data. A lot of people toss around the phrase "security through obscurity doesn't work" like it's a judeo-christian commandment - and yes, that's true, in the case of someone trying to write their own hashing algorithm. Better to use well established, well tested, secure methods. However, this **doesn't** apply to *physical* data. It is important for the data to be secured using well understood & tested methods - all of which are perfectly breakable by governments. A layer of obscurity (such as killswitches) goes a very long way to preventing **physical access to data.** >what happens when AWS reboots your instance I keep encrypted backups on an offshore server.