SQLAlchemy and You - <AUTHOR> http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ <comment><USER2> This article is by Armin Ronacher, the author of Flask. I use Flask for most of my projects because it's decoupled from the ORM and provides a clean way for you to use whatever database tool is right for the job.

But lately I have moved away from using the relational database as the primary datastore. When I do need a relational database, it's simple to use SQLAlchemy in Flask.

But I have been finding graph databases as a more elegant alternative to relational databases because you don't have to mess with tables or joins -- everything is explicitly joined.

Neo4j is one of the leading open-source graph databases, and it's pretty sweet -- it can store 32 billion nodes while doing 2 million traversals per second -- and you can use Gremlin with it (Gremlin is a graph query language, like SQL for graphs).

The graph-database world is starting to emerge, but most graph databases are Java based so non-JVM bindings are not always available.

However, there is a project called TinkerPop (<http://www.tinkerpop.com>) that has made most of the open-source software stack for graph DBs. TinkerPop is the project that developed Gremlin and Blueprints, and it released a REST service called Rexster that is tied to Blueprints so it lets you connect to any Blueprints-enabled graph database, including Neo4j, OrientDB, Dex, OpenRDF, and an InfiniteGraph implementation is being released next month.

Because the graph-DB world lacked Python support, I decided to write a Python persistence framework that connects to Rexster so you can now use any of those graph DBs from Python, and binary bindings are in the works. The framework is called Bulbflow, and you can find out more about it out at <http://bulbflow.com/overview>.

In a few weeks I'm going to release Flask-based libraries that do authentication and authorization in a graph-DB way.

<comment><USER3> You've been posting quite a bit about graph DBs lately including one the other day which stated that "the relational DB is dying as the primary datastore" as well as "Graphs are a much more elegant way of storing relational data". (source: <http://news.ycombinator.com/item?id=2778945>).

I have to disagree with you here. Graph DBs are a much more elegant way to store graph data, i.e. social media data, some forms of scientific data. But for the vast majority of relational database usage, i.e. finance, accounting, retail, medical records, human resources, academia, reservation databases, etc. the truly vast amount of databases we interact with indirectly all day long, these systems are firmly in the relational camp and that is not changing anytime soon. SQLAlchemy would very much like Python to be prevalent throughout all these industries, and is not just about social media applications.

<comment><USER2> Yes, that was in the context of Django as well. Look at the trend for MongoDB compared to PostgreSQL ([http://www.google.com/trends?q=mongodb%2C+postgresql&cta...](http://www.google.com/trends?q=mongodb%2C+postgresql&ctab=0&geo=all&date=all&sort=1)).

Because Flask is decoupled, it let's you use whatever tool is right for the job. If you need to store financial data, it's easy to use SQLAlchemy, but graph databases are much better fit for work working with stuff like the modern-day social graph.

And don't get me wrong, I like SQLAlchemy -- I have used it for years and continue to use it -- thank you for all the work you've put into it.

<comment><USER4> > Because Flask is decoupled, it let's you use whatever tool is right for the > job.

(Derail alert)

How is it any more difficult to use a graph database in Django? (Hint: if you say "but then you can't use X" my next question is "are you implying Flask includes X and you can automagically use X with a graph database?")

<comment><USER2> You absolutely can use a graph DB in Django. But if you're not using a relational DB as your primary datastore (for stuff like authentication and authorization) and not using the ORM, how much of Django would you really use?

Django was built around an ORM. Now you have more database options that have less of an impedance mismatch, but because Django is so ORM-centric, forgoing the RDBMS in favor of another option means you now have a framework mismatch.

Starting with Flask, which was designed to be decoupled, simplifies things.

<comment><USER5> "How much of Django would you really use?"

The URL mapper, the view abstraction, the middleware, the debugging tools, the generic views concept, the httprequest and httpresponse classes, the templating system, the caching framework, the syndication library and a bunch of the third party ecosystem tools.

<comment><USER2> Ahh...what you describe sounds a lot like Flask.

<comment><USER6> It sounds like every halfway decent web framework ever written.

<comment><USER2> The point is why not just start with Flask if that's the feature set you're going to end up with.

<comment><USER7> Becaus I'm more familiar and have experienced in using it. Because I decided to use Django for the other part of my big web application. Because I want to learn more and get better with my tool as opposed to learn the Python web app framework of the week.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> SQLAlchemy supports multiple-column primary keys, Django ORM does not. What's more to think about?

<comment><USER9> If I'm designing a schema, I always have a primary key column called "id" with an autoincrement sequence against it. Sometimes I'll have a domain table, with key varchar, description varchar.

Perhaps you deal with existing systems you didn't design. Aside from that - where is the cause to use a multi-column primary key?

<comment><USER8> There are strong opinions on it, but I firmly believe that "always have an autoincremental id" is a very wrong approach.

Read [http://it.toolbox.com/blogs/database-soup/primary-keyvil- par...](http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-i-7327) (an often-quoted series of blog posts on why surrogate numeric keys are evil).

In general, if you have an entity with a well-defined natural key (users and their logins, shipments and their tracking codes), why would you use an autogenerated key that's meaningless?

Case in point, my current schema, designed from scratch. Users can have multiple dashboards, each dashboard has a label. A user cannot have multiple dashboards with the same label, but the two users can of course use the same label for their dashboards (like "sales" or "mydashboard"). The dashboard's table primary key is (username, label) - that pair uniquely identifies a dashboard, so it's a perfect PK candidate.

Also, as already noted in one response, many-to-many relationships are typically modelled by an intermediate table that has foreign keys to both sides of the many-to-many, and its foreign key is the sum of these foreign keys.

EDIT: added a concrete example

<comment><USER9> Thanks to you and others for respectful responses on what I didn't realise was a hot-button issue.

You ask, "In general, if you have an entity with a well-defined natural key (users and their logins, shipments and their tracking codes), why would you use an autogenerated key that's meaningless?"

I like my approach because of reduced cog. overload. When I'm designing my database, or writing queries that jump through several tables, I always know that my foreign key in table Person [1] is going to be of the form fk_organistaion_id. All I have to do is remember table names and relationships. If I also had to remember arbitrary keys, that would increase memory overload. When I'm doing consulting and working on several applications in parallel that's less practical. Similarly, I always know I can store a reference to an ID column and know I'm it will be there and uniquely identify a row.

I don't think the many-to-many example really answers to my question. The issue of whether it is commonly done is different to whether it is good practice.

I can imagine there might be performance advantages to having a composite primary key for a join table. But - I expect you could get equivalent performance on id|fk_a_id|fk_b_id by adding an index. This comes back to the principle of - do you write your code principally to be run, or to be read. I have a memory like a sieve and write to be read.

I think composite primary keys are done for the wrong reason at times.

The problem in the example in the article linked to is not a poor use of keys, it's a poor design of system. They're trying to enforce type at the schema level. Though he doesn't spell it out, I expect the reason they're getting bizarreness is because they either have people interacting with the database at too-low a level, or because they have multiple applications hung off it. More on this in a second. [2]

Similarly, I think your attempt to use the database to enforcing typing rules will work at some levels but runs out. For example - imagine if a user was only alowed to have three labels. Or that the label musn't have any spaces in it.

While you can delve into triggers [3] I think it's misguided to think you can enforce a general sense of business logic at the database level. That stuff should be done by an application surrounding the database. Then all interaction with the database should go through that one-and-only-one system that owns the database.

Databases have some type information but it's very primitive and inadequate for all but the most simple of scenarios. I've found that once you acknowledge that you start designing schemas and the systems around them in a way that is very different to what you'd learn in the Oracle course.

\--

[1] Another quirk of my style - singular table names - because it makes it easier to wrap ORMs around it without having code that reads as bizarre

[2] The second example is riduculous. They assigned an int to the wrong place. That's not a problem with schema design, that's just a stupid mistake.

[3] I've done plenty of this work on hairy enterprise systems

<comment><USER8> I think I see the fundamental point where we disagree. I try to keep as much business logic in the database as possible. That's more of a DBA perspective, I guess: don't trust these pesky app developers, always assume they'll try to put broken data in your DB.

It's often not possible to model all business rules in SQL, but the more you manage to cram into the database, the less probable it is you'll end up with inconsistent data.

Often there are dozens of applications (or independent modules) using the database. Keeping the business rules (like "every user has to have a first name" or "no two customers can rent the same car at the same time") in a centralised place helps a lot with keeping everything in order. It's often not possible to limit the interaction with the database to a one-and-only system (imagine different teams writing different parts of the system, app changes, outsourced integrations, etc)

So, if a label can't have spaces in it, that's easy - slap on a check constraint that enforces it. Then you know that even if the new hire writes a "change my label" funcionality and forgets to enforce the no spaces rule, she won't screw up your data.

If a user can have at most three labels, things get more interesting. Offhand I'm not sure how I'd model that and it actually is a difficult problem, best solved with triggers IMHO, as you have better control over locking and can guard yourself against concurrency issues.

Anyway, the discussion on "all logic in DB" vs "all logic in the app" is part of the neverending struggle between DBAs and app programmers...

<comment><USER9> haha I can see why we disagree. Same problems, different solutions.

        Often there are dozens of applications (or independent
        modules) using the database

I know! I always assume that someone will try to pull this on me, some shortsighted bugger always does, and I end up on crusde protecting my platform against this!

It is fundamentally bad design to have more than one application dependent on a database, and you're right, it's used everywhere. If I do a PhD one day, it will be on this topic. It's the number one stupid design in enterprise computing.

I've spent years trying to write a logic framework to surround schemas to make it possible to do the functionality of pl/sql, but with stateful sessions. Every eighteen months I have a new go at it and rewrite.

I have the ideas working, and use the patterns now, but haven't managed to create a framework of it that would be usable to anyone else.

        Anyway, the discussion on "all logic in DB" vs "all
        logic in the app" is part of the neverending struggle
        between DBAs and app programmers...

Yeah. When I was doing a lot of relational work, I'd enforce these checks by having business logic layers around my ORM.

</comment></comment></comment></comment></comment></comment><comment> j-kidd I think SQLAlchemy is designed for people who are comfortable dealing with SQL directly, while other ORMs want their users to be oblivious about SQL.

In Chinese, there are 3 stages of life:

1\. Looking at a mountain, it's a mountain - this is when you start learning about SQL

2\. Looking at a mountain, it's not a mountain - this is when you start using tools that shell you from SQL

3\. Looking at a mountain, it's still a mountain - this is when you start using SQLAlchemy

</comment><comment><USER10> _Many people's first experience with a Python ORM (or maybe an ORM altogether) is the Django one._

Useless anecdote: I started out using SQLObject since I was importing data from flat files into a relational database, then doing some analysis. When the analysis became useful to others, that's when I started building a web front- end with Django.

</comment><comment><USER11> SQLAlchemy is pretty much the only ORM I've used that DIDN'T suck. It's great, especially after seeing Java / Hibernate hell.</comment>


Ask HN: Current Crypto Best Practices - <AUTHOR> For a run-of-the-mill programmer, where are some places that I can look for crypto best practices?  Eg. For storing passwords, Coda Hale's https://codahale.com/how-to-safely-store-a-password/ looks like it is still relevant, but how do I know that? I know that cperciva and tptacek are some go-to people on HN, but where can I point other non-HN readers? <comment><USER2> If you come from a computer science/math background, and want an intro to cryptography in general, I can strongly recommend the Coursera course from Stanford University by professor Dan Boneh - [https://www.coursera.org/learn/crypto](https://www.coursera.org/learn/crypto). To really understand the implementations of security libraries and tools, one should be at least familiar with the fundamentals and terminology of crypto. Otherwise you are blindly encrypting things without being aware of whether you are actually securing things.

The course is free and takes 6 weeks long, and is very interesting if you had never dwelled too deep into security or crypto. There's also a new cryptography class that will be available in September of 2017 - [https://www.coursera.org/learn/crypto2](https://www.coursera.org/learn/crypto2).

<comment><USER3> TBH this doesn't really give you anything about best practices though. It's a bunch of base theory without anything about timing analysis, etc. It's nice to know information but I don't think it makes you a better 'secure' programmer.

<comment><USER4> This was a complaint I heard from several people I work with who took the course.

<comment><USER5> To my knowledge there has never been a timing attack documented in the wild on a remote server. They are only practical in offline scenarios with host access

<comment><USER3> Depends on what you mean by timing attack.

The only vulnerability of Tor, which heavily depends on cryptography, is timing analysis.

One of the most important lessons of cryptography is that it doesn't exist in a vacuum. Timing between messages and message sizes can be enough to end you.

<comment><USER5> I guess "timing analysis" means something else, more akin to correlation of meta-data. [https://en.wikipedia.org/wiki/Timing_attack](https://en.wikipedia.org/wiki/Timing_attack) is pretty clear, so maybe I was referring to something else than the OP.

</comment></comment></comment></comment></comment></comment><comment><USER6> Cryptographic Right Answers is a good place to start

[https://gist.github.com/TheZ3ro/fb521a3cde0c91fcb350](https://gist.github.com/TheZ3ro/fb521a3cde0c91fcb350)

<comment><USER7> The original from tqbf: [https://gist.github.com/tqbf/be58d2d39690c3b366ad](https://gist.github.com/tqbf/be58d2d39690c3b366ad)

It's definitely completely relevant today. Find out what you want to do and check that list.

A few things I would update:

* password handling -> Scrypt or Argon2

* Client-server application security -> TLS or Noise

* Hashing/HMAC algorithm -> Blake2/prefix-MAC or KangarooTwelve/KMAC

* Fingerprint -> TupleHash

* key derivation -> HKDF or SHAKE or BLAKE2X

And of course for each of these items, if a NaCL/libsodium solution already exist, just use it.

<comment><USER8> Why would you make those updates? I like Noise more than I like TLS, but if you look at the recommendation where it says "use TLS" and ask yourself "how would I as a Python application programmer actually use Noise", I don't see the applicability.

Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally available and strong (in the context of those recommendations, I also didn't want to explain the difference between SHA-2's HMAC and Blake2's keyed hash MAC). And, of course, part of the point of recommending SHA-2 was to recommend _against_ Keccak. :)

I don't think I actually made a key derivation or fingerprint recommendation. I like HKDF!

<comment><USER7> > "how would I as a Python application programmer actually use Noise", I don't > see the applicability.

Depending on who that list is for I could agree with you.

This recommendation comes from the fact that I'm seeing a LOT of companies who want to have their own secure protocol on top of whatever protocol and end up re-inventing the wheel to avoid the bloatness of TLS. Noise is a good advice for these custom made protocols. I wouldn't replace TLS in the advice, but add a note: "if you really do not want TLS, there is Noise, but that's it!

> Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally > available and strong

Agree, but if we want to move to nicer/stronger algorithms we must start recommending them at some point. I want to see a push for Argon2/Blake2/SHA-3 in general.

> part of the point of recommending SHA-2 was to recommend against Keccak

Ah well, Keccak is so interesting (not only for hashing) that I would be sad if it end up not being used in the next decades to come. If you're feeling this way because of the efficiency: that's why I recommended KangarooTwelve, if you're feeling this way because of the crappy spec: alright you win.

> I don't think I actually made a key derivation or fingerprint > recommendation. I like HKDF!

What are you waiting for! :)

<comment><USER8> There's more recommendations I could make; for instance, I talk about DH here but not about authenticated key exchanges. But at some point I'm no longer providing simple "right answers" and instead am writing a half-assed book on modern crypto that I'm not qualified to offer.

The more important bit here is that I was updating Colin Percival's recommendations, which didn't include a KDF or an AKE. :)

</comment></comment></comment></comment></comment><comment><USER9> I'm surprised to see so few recommendations for libsodium. [https://download.libsodium.org/doc/](https://download.libsodium.org/doc/)

For pretty much any crypto task that a "run-of-the-mill programmer" is likely to run into, they've got you covered.

Secret key encryption: [https://download.libsodium.org/doc/secret- key_cryptography/a...](https://download.libsodium.org/doc/secret- key_cryptography/authenticated_encryption.html)

Password hashing: [https://download.libsodium.org/doc/password_hashing/](https://download.libsodium.org/doc/password_hashing/)

<comment><USER10> I would go for TweetNaCl instead.

The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous.

Most people don't need SSL. Most people don't need a zillion choices.

Most people need a _single_ choice that actually works and is resistant to programmer error.

<comment><USER11> Isn't the attack surface limited to the methods used in the application though? Even if libsodium has a vulnerability in some ABC method, unless the application in question uses that code path, it's not an immediate risk (Obviously it should get patched and stable, secure software is preferred over the alternative). I'm just trying to understand how the "attack surface" is calculated, and how a potential vuln in an unused method is a huge risk.

<comment><USER10> > Isn't the attack surface limited to the methods used in the application > though?

No, because the combination of how you put them together can make you vulnerable.

For example, if you are encrypting lots of messages that all have the same header, certain crypto algorithms can be made to leak the key.

Do you know which combinations those are? I sure don't by default.

The fact that an end programmer even has to think about this is the problem.

In any cryptosystem, the application programmer is the person who knows the least about crypto. If he has to make _any_ decision, you can expect he will get it wrong.

<comment><USER9> Good points. I was about to say something about how libsodium will take care of most of that for you.

For example, I thought they provided some facility for avoiding nonce reuse vulnerabilities by automatically generating pseudorandom nonces for the user.

But then I double checked their API docs and they don't do this at all! Argh!

</comment></comment></comment></comment></comment><comment><USER12> Cryptography Engineering [0] is a great book that covers key topics in cryptography with a focus on best practices for implementors and system/protocol designers.

Matthew Green's blog, A Few Thoughts on Cryptographic Engineering [1], has a wealth of interesting posts that are often aimed at explaining cryptography to a "technical but non-cryptographer" audience, and tend to be motivated by recent events in security/cryptography news.

[0]: [https://www.amazon.com/Cryptography-Engineering- Principles-P...](https://www.amazon.com/Cryptography-Engineering-Principles- Practical-Applications/dp/0470474246) [1]: [https://blog.cryptographyengineering.com/](https://blog.cryptographyengineering.com/)

</comment><comment><USER13> The IT Security StackExchange website contains lots of information which is generally kept reasonably up to date. For example a TLS answer might be a bit old and not list last week's attack, but if something turns incorrect it will often be edited.

[https://security.stackexchange.com](https://security.stackexchange.com)

</comment><comment><USER14> OWASP has some nice guidelines on a lot of topics, including storing passwords.

Start at [https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)

<comment><USER8> OWASP's cryptography advice is almost invariably awful, and that password storage thing is among the worst of it. It's better now than it was when it recommended against password hashes (note that it still recommends "cryptographically strong salts") but remains factually incorrect in more than one place, including the notion that PBKDF2 is better than bcrypt (the opposite is true).

<comment><USER15> Agree that OWASP's crypto advice is generally garbage, but is there a better salt policy than what they have?

        [protected form] = [salt] + protect([protection func], [salt] + [credential]);

<comment><USER16> I assume tptacek's objection is that salts need to be unique (at most, unpredictable enough to discourage precomputation), and don't need to be produced by a CSPRNG.

Edit: or maybe something else from the editorial history of the document?

<comment><USER8> There's that, but more generally and importantly, application developers who take special measures to generate salts tend _not_ to be using secure password hashing algorithms --- the libraries for things like bcrypt tend to handle this for you.

<comment><USER16> Maybe akin to the "typing the letters A-E-S" in [https://www.nccgroup.trust/us/about-us/newsroom-and- events/b...](https://www.nccgroup.trust/us/about-us/newsroom-and- events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre- doing-it-wrong/)?

</comment></comment></comment></comment></comment></comment><comment><USER8> The answers for this depend on what you're trying to do. Can you be more specific? Coda's password storage advice is still the best advice for people who don't know what they'd do otherwise.

</comment><comment><USER17> I'm currently building a community website for these kind of questions (storing password, constant-time token comparison), the design is pretty raw for the moment: [https://sqreen.github.io/DevelopersSecurityBestPractices/saf...](https://sqreen.github.io/DevelopersSecurityBestPractices/safe- password-storage/python)

The code examples are in Python, but I plan to add pages in other languages.

</comment><comment><USER18> The golden rule about storing a password is to not store a password... I can't wait till SQRL takes off

<comment><USER19> It won't. See [http://security.blogoverflow.com/2013/10/debunking- sqrl/](http://security.blogoverflow.com/2013/10/debunking-sqrl/) for a myriad of reasons.

I've also come to realize that one should take everything that SG says with a large table spoon of salt.

<comment><USER20> > The proposed SQRL scheme derives all application specific keys from a single > master key. This essentially provides a single juicy target for attackers to > go after.

That sounds like the same problem password managers have. And yet they are still recommended over (re-)using your own passwords for each website.

<comment><USER21> The crucial difference is that with a password manager, passwords are _protected by_ a master key, but not _derived from_ it. So you can rotate passwords whenever you want, either proactively or reactively, mitigating the effects of a password database compromise.

</comment></comment></comment></comment><comment><USER22> Dan Boneh's Coursera course is ideal for any beginner. Cryptography Engineering by Schneier et al. is good, as is Ross Anderson's Security Engineering, but both are fairly dated.

The OWASP guidance is OK for a quick access to best practices, but insufficient for rigorous learning.

Cryptography takes time to digest the fundamentals and recognise how new concepts are both beneficial and, vitally, disadvantageous; sadly, there is no cheat sheet or quick fix.

Source: computer security PhD student.

</comment><comment><USER23> Quick sites:

* PyCon Crypto 101 - [https://www.crypto101.io/](https://www.crypto101.io/) (and if you use Python, please use Cryptography library for encryption/decryption please, Python built-in provides sha and hmac already though, and please adopt your framework's security implementation whenever possible).

* Mozilla Web Security Guidelines - [https://wiki.mozilla.org/Security/Guidelines/Web_Security](https://wiki.mozilla.org/Security/Guidelines/Web_Security)

* Mozilla Secure Coding Guideline - [https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines)

* Mozilla Server Side TLS - [https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)

* Mozilla Intro to Cryptography (slide: [https://april.github.io/crypto-presentation](https://april.github.io/crypto-presentation) video: [https://www.youtube.com/watch?v=bg32spD2mB0](https://www.youtube.com/watch?v=bg32spD2mB0))

* Mozilla Web wiki - [https://developer.mozilla.org/en-US/docs/Web](https://developer.mozilla.org/en-US/docs/Web) (understand CORS, Cookies, CSP, etc)

* Google's course on security - [https://google-gruyere.appspot.com/](https://google-gruyere.appspot.com/) (original course page has been taken down by Google already)

Book recommendations:

* The Web Application Hacker's Handbook

* The Tangled Web: A Guide to Securing Modern Web Applications (written by the famous Michał Zalewski working at Google, and lately known for developing the American Fuzzy Loop AFL which has been used for uncovering many new CVE bugs).

* Hacking: The Next Generation

* Securing DevOps (to be released soon)

Publications:

* USENIX - [https://www.usenix.org/](https://www.usenix.org/) (tons of free high quality conference talks, I like USENIX over ACM)

* Real World Crypto

Getting real

* Go find bug bounty program out there, many well-written posts how one discovered bugs

* Follow a bunch of security engineers / security-minded folks on Twitter (e.g. @matthew_d_green would be a good start)

OWASP is a great reference, you read it as an index page. But like others have pointed out, the Wiki is often outdated, but concepts almost always remain the same. Use multiple resources before implementing a solution, and never just copy and paste solution posted by others on Stackoverflow. Sorry for so many Mozilla stuff definitely there's some bias from me but I trust folks running the sec team there.

</comment><comment><USER24> A good guide for password hashing is [https://paragonie.com/blog/2016/02/how- safely-store-password...](https://paragonie.com/blog/2016/02/how-safely-store- password-in-2016) . I think your codehale link is out of date since it's from 2010.

<comment><USER25> Not bad, but I found this questionable:

> The other Password Hashing Competition finalists (Catena, Lyra2, Makwa, and > yescrypt)

These were promoted above PBKDF2; algorithms with few implementations. PBKDF2-HMAC-SHA-512 with sufficient iterations is typically robust, and has been scrutinized.

I personally prefer scrypt, but in lieu of a solid scrypt or bcrypt lib I wouldn't hesitate to lean on PBKDF2 over the others.

Argon2i was in the same boat but being in libsodium went a long way to reinforcing trust, although Argon2i and Argon2d should really have had distinct names.

<comment><USER26> The page gives solid rationale against PBKDF2:

 _Although PBKDF2 is more widely available than bcrypt or scrypt, it doesn 't offer the GPU resistance that we need from a password hashing function. If you must use PBKDF2, make sure you use at least 100,000 iterations and a SHA2 family hash function.

To reiterate: PBKDF2 can still be secure. It's the least secure of the acceptable password hashing algorithms on this page, so we aren't going to provide any example code._

</comment></comment></comment><comment><USER27> I made this a while ago: [http://howtostoreapassword.com](http://howtostoreapassword.com). Still relevant I think. :)

I should probably update it to use one of the more modern algos, but the availability of good bcrypt libraries makes it solid advice still.

<comment><USER28> That was pretty comical. I don't know if it is just my connection but it seems to take a pretty long time to load a page with a relatively small amount of content.

</comment></comment><comment><USER29> Not necessarily best practices, but I recommend the Matasano Crypto Challenges to basically everyone. I make all of the developers on our team do them too:

[http://cryptopals.com](http://cryptopals.com)

<comment><USER30> Those challenges teach vulnerabilities in old, low level cryptographic primitives. As much as I enjoyed those challenges, they are not a good place to start for a developer trying to build a secure application.

<comment><USER8> Low level, yes. But, old? We cover AES, HMAC, stream ciphers, GCM, RSA, DH, SRP, and elliptic curves. The criteria for inclusion on the first 6 sets of challenges was "had to be something we took advantage of on the job at Matasano". It's not textbook stuff.

Part of the point of the crypto challenges was to illustrate why people shouldn't work directly with low-level primitives, as a sort of antidote to the kind of advice OWASP gave out.

<comment><USER31> The first set of problems are all very simple, but you have to start somewhere.

I'm not sure that the cryptopals chalelnges are the best way to learn exactly how you should be implementing everything, but I've found the knowledge that I gained from doing the challenges very applicable in my daily job and definitely helped further my understanding of crypto in a way that reading a book just couldn't do.

<comment><USER32> Part of the point that I got with cryptopals is how easy it is to break stuff that you thought was hard to break.

There is a theory that we practice on my team that you don't really understand something unless you try to break it. And this team regularly tells developers facts about their programs and systems that previously unknown to them.

</comment></comment></comment></comment></comment><comment><USER10> So, what's the recommendation for an Authenticated Key Exchange?

I see a lot of "don't use" but I don't see any "do use" for that case.

</comment><comment><USER33> May be on a tangent and a shameless plug, but I just posted [https://news.ycombinator.com/item?id=14042150](https://news.ycombinator.com/item?id=14042150) this morning.

Underlock is a small Ruby library that helps with Encrypting/Decrypting of files and other data.

<comment><USER8> Unfortunately, I think libsodium remains a categorically better answer for this problem.

</comment></comment><comment> nommm-nommm OWASP (non-profit)

[https://www.owasp.org/](https://www.owasp.org/)

NIST (government)

[https://www.nist.gov/publications/](https://www.nist.gov/publications/)

<comment><USER34> FYI I think you're getting downvoted because NIST is known to have recommended a pseudo-random number generation algorithm that is believed to have been intentionally designed with a backdoor [1], presumably by some US 3 letter agency.

OWASP seems like a decent source for learning about security topics at a high level (particularly web app security).

[1][http://dualec.org/](http://dualec.org/)

<comment><USER23> I didn't follow that discussion closely, so I will avoid the argument here on that subject. Overall, NIST is a good resource for comparison. If you work with government, enterprise security, or compliance, you want to go through NIST. If you have spare time I recommend read [https://beta.csrc.nist.gov/publications](https://beta.csrc.nist.gov/publications).

NIST is also responsible for running [https://nvd.nist.gov/](https://nvd.nist.gov/) which is a great asset for finding CVE.

<comment><USER35> I agree. They got subverted at one point by an organization they thought was helping them. Their overall catalog of advice is OK in that it's a lot of the stuff readers would hear from people they paid for IT or INFOSEC advice. Just free instead. A good example are the recommendations in this one for small, business owners that don't know anything about INFOSEC:

[http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.7621r1.pdf](http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.7621r1.pdf)

DISA has the "STIG's" for security configuration:

[http://iase.disa.mil/stigs/Pages/index.aspx](http://iase.disa.mil/stigs/Pages/index.aspx)

The NSA themselves, the Information Assurance Directorate, had guides on hardening various things. There's one for deploying Chrome in the link below that also references STIG on Chrome:

[https://www.iad.gov/iad/library/ia-guidance/security- configu...](https://www.iad.gov/iad/library/ia-guidance/security- configuration/?page=3)

It would be straight-forward for INFOSEC people to vet the NIST or STIG guides for content accuracy then host that copy on their own sites. Or produce similar guides as some do. Just important to target them at people of low knowledge or competence so they know exactly what they need to do. It's them whose hardware will become part of the next DDOS due to configuration error.

<comment><USER34> > They got subverted at one point by an organization they thought was helping > them.

Fair points, shouldn't throw the baby out with the bathwater etc. But as a governmental agency, do they have the autonomy to avoid being similarly subverted in the future? Not rhetorical, I genuinely don't know how they are governed/if they can refuse the "help" of the 3 letter agencies.

Which makes me realize, the 3 letter agencies may have still benefitted by the Dual_EC_DRBG scandal coming to light - what they lost in a backdoor, they gained in a chilling effect on the spread of good crypto practices by staining NIST's reputation.

<comment><USER35> "do they have the autonomy to avoid being similarly subverted in the future? Not rhetorical, I genuinely don't know how they are governed/if they can refuse the "help" of the 3 letter agencies."

It could happen to anyone if it's about receiving bad advice from an authority with a conflict of interest. That's why the solution is to either produce good advice for each of the things they're talking about or vet their advice to see if it contains any problems.

"what they lost in a backdoor, they gained in a chilling effect on the spread of good crypto practices by staining NIST's reputation."

I never thought about that. I doubt they intended that but it might be a real benefit for SIGINT side. That's interesting enough angle I'm going to bring it up to regulars on Schneier's blog who discussed the NIST stuff a lot.</comment></comment></comment></comment></comment></comment>


Breaking Hard-Disk Encryption - <AUTHOR> http://www.schneier.com/blog/archives/2012/12/breaking_hard-d.html

<comment><USER2> If we have memory dump it is easy to find the key. Nothing new.

Defenses are - never sleep the damn thing or hibernate just power off. And make sure you do not have any DMA ports on the PC. And finally - hope you live in a country where the cops are not proficient in thermorectal cryptoanalisys.</comment>


Digital Ocean: $10/$65 USD coupon codes (for new customers) - <AUTHOR>

Get a Linux SSD powered VPS right now with this new (and exciting) promo DigitalOcean it's offering.
Steps:
1. Go to: https://www.digitalocean.com/?refcode=454a567a70f6 and create a new account
2. Click Billing
3. When asked for it, use the code : CHEFCONF ($65) - SSDMAY10 ($10)
4. Pay $5 with Paypal and/or a Credit Card (to verify your account)
5. Create a new "Droplet" (starting at $5/month)
6. Get up to 13 months of a $5 VPS with the following characteristics:
512MB / 1 CPU 20GB SSD DISK 1TB TRANSFER
Disclaimer: The DigitalOcean URL up there is my referral link which you can use to help me out a little.
Enjoy! <comment><USER2> Incorrect Promo Code! Code has expired

<comment><AUTHOR> Just tried it out a few hours ago and it was working, can other readers please confirm the above comment? Promo is suppoused to work until May 31, 2014 as far as I know...

Thanks.

</comment></comment><comment><USER3> Code doesn't work. It looks like your trying to get people to register with your referral code.

<comment><AUTHOR> Yep, that's on the "Disclaimer" part.</comment></comment>


Google Acquires Video Compression Technology Company On2 For $106 Million  - <AUTHOR> http://www.techcrunch.com/2009/08/05/google-acquires-video-compression-technology-company-on2-for-106-million/?awesm=tcrn.ch_3Ao8&utm_campaign=techcrunch&utm_medium=tcrn.ch-twitter&utm_source=direct-tcrn.ch&utm_content=twitter-publisher-main <comment><USER2> So remember there was a flurry of talk about what was going to kill Flash a few months back?

This (meaning Google's fairly clear intention to make some kind of royalty free video codec from what it's just bought) has just killed Flash and moved the web forward about 5 years.

I wonder if they'll create a new standard around the technology (perhaps pair it with the Ogg container format or with Vorbis audio, run it past some standards org like IETF) and/or release it as is.

It's a fairly big move for Linux Multimedia support too.

<comment><USER3> I don't think this is going to kill flash, or at least not for a while. The speculation that Google is going to switch YouTube over to HTML5 any time soon is quite far fetched. They would be alienating a large part of their user base.

What this does provide is the possibility to have a universally supported HTML5 video codec. At the moment, there isn't a single one that is going to be supported by all browsers. Without a well supported codec, HTML5 video tags are basically useless in production. This new deal doesn't automatically kill flash, but it does somewhat level the playing field between flash and HTML5 in terms of video.

<comment><USER2> Youtube already has specialist interfaces for smartphones, iPhones, Big screen TVs, and 6 or 7 different Flash versions based on quality/bitrate, size and codec. They can easily add another using HTML5, particularly if it provides a better experience for those using Google's Chrome browser or OS.

YouTube native on the iPhone was already a major blow to Flash (as was the whole touchscreen phone/computer paradigm). This _will_ kill it (in conjunction with a bunch of other stuff Google is pushing under the umbrella of HTML5).

Video in Flash has always been an aberration created by dodgy patents, licensing considerations and competitive posturing of big companies, now the market can correct itself and Flash (for video and otherwise) is going to have to compete on its own merits. In brief: dead man walking.

<comment><USER4> I really hope you're right. I would love nothing more than to see flash go the way of .rm

</comment></comment></comment></comment><comment><USER5> VP8 is an amazing codec. If Google makes it available under FOSS terms, it would be huge. It's more CPU friendly than H.264 while providing better quality. Wow. Maybe it's a little far-fetched to think that Google would spend $106M to open-source something, but when you think about it many companies have paid more to do the same (or for things that were already open source). Novell paid $210M for SUSE. Sun paid $1B for MySQL. And having the best video codec as a free codec does fit with Google's open strategy.

And it might even be cheaper over the long run. Remember, while H.264 is free to broadcast right now, there are fees coming in a year or two just for pushing H.264 over the web. If nothing else, Google's ownership of On2 provides a hedge against getting hit too hard by royalties.

<comment><USER6> One hundred and six million dollars is nothing in this game.

Youtube acquisition price. 1.6 Billion <http://www.msnbc.msn.com/id/15196982/>

Youtube estimated daily losses 1.65 Million [http://www.internetevolution.com/author.asp?section_id=715&#...](http://www.internetevolution.com/author.asp?section_id=715&doc_id=175123&);

They could pay that shit off by Thanksgiving if they push a browser plugin out by mid September.

<comment><USER7> When are people going to stop citing the wildly inaccurate Credit Suisse report? <http://news.ycombinator.com/item?id=573281>

</comment></comment></comment><comment><USER8> This is an excellent strategic move by Google and further evidence to the notion that Google is trying to marginalize the various core elements of the Internet experience (<http://news.ycombinator.com/item?id=693861>). If they open up VP8 and have it become the default built-in video codec for HTML5 browsers, it puts a lot pressure on Apple and Microsoft and even Adobe. At the price they paid, it was definitely a great deal for them.

</comment><comment><USER9> A reddit comment on this purchase says this:

      Google tends to look a few steps ahead.
      Remember that whole debacle with GOOG-411
      and speech recognition? They intend to use
      the free GOOG-411 service to improve their
      speech recognition so that YouTube videos
      can eventually have automatic closed captioning,
      and can -- in turn -- be searchable by Google
      and can offer a whole new era of video search
      results.

The automatic closed captioning is especially interesting. Any truth to it?

[http://www.reddit.com/r/technology/comments/97rc8/if_youtube...](http://www.reddit.com/r/technology/comments/97rc8/if_youtube_is_causing_google_to_lose_millions_a/c0bpz24)

<comment><USER2> Part of Google Voice is automated transcription of voice mails.

It's still not perfect, but like close captioning and OCR of books, it doesn't have to be 100% to be useful for search purposes.

</comment></comment><comment><USER10> worst case scenario: One more codec we have to encode videos in if they were to be supported by the <video>-tag: Safari uses h.264, Mozilla uses Theora and Chrome now uses any of the newly acquired codecs to save on h.264 license fees.

Before this, we just had h.264 and Theora.

Better scenario: Google opensources some or all of the acquired codecs and gives a free patent license (I don't think they can give the patents away to public domain, can they?) at which time, we'll have Safari on one side and Chrome / Mozilla on the other which basically is the same as we had today, but reversed.

Best-case scenario: As above, but the HTML5-guys agree to actually mandate the use of one of these new codecs forcing compliant browsers (this then may include Safari) to implement them and thus we only need to encode the video once (assuming youtube supports the new codec aswell, because we'll need to still fall back to youtube for IE).

Or anything in between.

Just don't get your hopes up.</comment>


The Worst Room - Photos of Cheap Rooms for Rent in NYC - <AUTHOR> http://theworstroom.tumblr.com/ <comment><USER2> For all of the people in this thread saying "some of these aren't that bad" you seriously need to get some perspective. Come visit what's disparagingly called "flyover country." I live in the St Louis area and pay $450/month for my apartment. ~1100 square feet with a yard and a parking spot in a nice, safe neighborhood.

I fully realize that I may not have all of the opportunities available here as I would in NYC or San Francisco, but I've never struggled to find interesting, well paying jobs and there is more than enough going on in the St Louis area to keep a person entertained.

Far be it from me to judge other peoples' choices. You should do whatever makes you happy in life but, when you find yourself saying that a room the size of my closet "isn't so bad" of a living space, you might want to take a step back and reassess some things.

<comment><USER3> _For all of the people in this thread saying "some of these aren't that bad" you seriously need to get some perspective._

7-year New Yorker here.

By NYC standards, they aren't that bad. They're unattractive and small, but I've seen _a lot_ worse.

Some of the places that I've had realtors show me make these places look like palaces. When I first got here and was living on close to nothing, I found (on Craigslist) a Williamsburg loft where there'd literally be a shower curtain separating my "room" (which was filthy) from a dark, tenement-like space with ~12 people in it. Kitchen stuff was at least 50 years old and probably didn't work. I visited at 10:00pm on a Thursday and it was loud as hell. $1200 per month. Um, no thanks. (By the way, Williamsburg has the most intense negative energy on earth. Hipsters sound okay in theory but I can't fucking stand them in practice. To give one a job is like pouring salt on a slug, except a good thing in the former case because the whining is entertaining.)

However, I agree with you. If you can get a stream of good jobs out in the Midwest, that is the way to go.

It's honestly not worth the cost of living here for most people. The high rents here are driven by (a) asshole foreign speculators that the government irresponsibly lets into the market, when a 6-months-and-1-day rule is really in order, (b) various legacy rent-control systems that wouldn't be a big deal except in the context of extreme price inelasticity-- I have no problem with the idea of rent control, or even with its continuation for the legitimate beneficiaries; but when upper-middle-class well-connected asswipes buy their way into an arrangement that's superior to ownership, and lock up housing stock, that's wrong, (c) NIMBY like you wouldn't believe, (d) parentally- funded hipster zeros whose guilt-ridden spawners decided they have some entitlement to the "New York Experience" (at $2-6k/month) even though they do absolutely nothing for anyone, (e) the fact that in investment banking and large-firm law, there really are major career benefits to living here (you pretty much need to live in Manhattan to get promoted in soft-side banking; trading is more of a meritocracy where you can live whereever you want as long as you show up on time). If none of these apply, New York is not worth the cost of living here. It is nice, if you take out the cost problem; I just think having savings and, eventually, the freedom with having a nest egg, improves the average person's quality of life by more. (You might guess that I don't intend to be here in 10 years, although I'm very glad I spent the 7 that I have.)

<comment><USER4> >>>7-year New Yorker here.

>>>The high rents here are driven by (a) asshole foreign speculators that the government irresponsibly lets into the market, when a 6-months-and-1-day rule is really in order, (b) various legacy rent-control systems that wouldn't be a big deal except in the context of extreme price inelasticity

Um, no. Second-generation life-long New York _native_ here.

These insane prices are driven up by people like _you_ who come here, don't know the proper prices, don't know _why_ the hell we have rent control or what it is and never check to see if you're being ripped off, and so drive everything the hell up. Period.

<comment><USER5> These insane prices are drive by people like you who don't know how to do math. <http://en.wikipedia.org/wiki/Rent_control_in_New_York>

As of 2011, more than 60% of all apartments in New York are price regulated in some way. Rent stabilization destroys the incentive for developers to maintain and improve properties, and combined with the ridiculous historical preservation laws binds their hands in replacing properties with higher- capacity housing.

That's why most of the housing in Brooklyn and Queens is former tenement housing built god knows how long ago and maintained like crap. Landowners can't easily decide to just tear that shit down and put up mid/high-rises that could house 10x more people and bring down prices.

<comment><USER4> >>>and put up mid/high-rises that could house 10x more people and bring down prices.

Except rent prices _never go down_. This is what you outsiders don't freakin understand. Even if you got rid of the rent control and stabilization laws, made it all "free" market, you'd _never, ever_ see a decrease in rents. When people fled post-9/11 and no one was renting, rents did not go down. They side-stepped that by offering one or two or three months of "free" rent, while the registered rent remained in the city's books. _Rents never decrease._ And never will unless there is some catastrophe that makes the city inhospitable.

<comment><USER5> First, there is no reason to believe outsiders to NYC have a better or worse grasp of the underlying economics than insiders to NYC.

Prices in NYC do go down. Rents in NYC fell 10-12% during the down turn (and of course 2-3 months of "free" rent is economically indistinguishable from a drop in rents).

Moreover, rents are sticky like most prices. What increased supply does is keep the rent from going up so quickly.

<comment><USER3> _(and of course 2-3 months of "free" rent is economically indistinguishable from a drop in rents)._

I hate the "free months" with a passion, because they carry an implicit rent- raise next year: even if rent stays the same, your effective rent rises because you're paying for 12 months instead of 11.

I usually try to negotiate the "free months" into a lowered rent (e.g. $2250/month instead of $2400 with a one-month concession). It means that I pay a little more in the first year, but next year's rent will be anchored to this year's.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> A few of those, for the prices that they are, would be great with the current furnishings removed / decent furnishings brought in. There is a time in my life where I would have jumped through hoops to rent some of those.

For example that 300/mo "Breakfast Nook" one looks like it would be perfectly fine with the other person's shit removed.

(I am not a resident of NYC)

<comment><USER7> I'm fairly certain the "Breakfast Nook" is renting JUST the nook at the very end, and the kitchen is a shared space.

<comment><USER6> Hmm, yes. For that price, that _would_ make much more sense.

Even so, it could be fine with the right roommates (is that mess made by the previous tenant, or the person/people that would still be living there?). If the kitchen is a shared space that price could actually be fantastic if there is further shared space that isn't pictured (though I doubt there is).

</comment></comment></comment><comment><USER8> _> Appalling_

Lets have a little perspective [0].

0: [http://www.slate.com/blogs/future_tense/2013/02/22/_60_perce...](http://www.slate.com/blogs/future_tense/2013/02/22/_60_percent_of_the_world_population_still_without_toilets.html)

<comment><AUTHOR> Sure, but the price is what makes the condition appalling.

</comment></comment><comment><USER9> These look pretty good to me - and the rents are actually reasonable. Crappy Palo Alto Studios are pushing $2k and it's hard to find anything cheaper than $1300 even in a share.

</comment><comment><USER10> This reminds me of Hong Kong apartments shots:

[http://petapixel.com/2013/02/19/cramped-apartments-in- hong-k...](http://petapixel.com/2013/02/19/cramped-apartments-in-hong-kong- shot-from-directly-above/)

</comment><comment><USER11> I'm now looking around my London room (rent approx $1000/month; other living spaces shared) and realizing that with its L-shape and slight roof overhang, it probably works out smaller than half the ones featured on the NYC blog, though it does have a window.

On the other hand, the ad I responded to mentioned a "roof terrace" which would have elicited a few chuckles if they'd put up a picture of the wobbly ladder leading to the standard flat roof. Funnily enough, its a dubious feature I actually like for the views and the way it catches the sun rather better than the _bona fide_ garden I had in my last place. I quite like walking everywhere too...

<comment><USER12> I've been living in London myself for little under two years now and I still can't get my head around the rents. Heaven forbid you want to live on your own as a young person...

I've also lived in Berlin. And yet somehow that city didn't seem to have the rent problems other capitals seem to. I have no idea why.

</comment></comment><comment><USER13> Those ... really aren't that bad. Well, not all of them at least. Some of them even seem quite livable. Maybe we need to see room dimensions or something? If they're all 5x7 feet or something, that might be a bit more understandable

<comment><USER14> A lot of them could just be pictures of the corner of a room. Without context it's hard for me to say they're terrible.

</comment></comment><comment><USER5> God, coming from Chicago I find the New York housing market to be such a disaster (though I live in Westchester so I put my money where my mouth is, I guess). I remember paying $1,800 a month of a 250 square foot room on the UWS where the closet had been turned into a bathroom. I lost weight that summer, because I was literally so disgusted by the filth of all the old buildings. I remember visiting an apartment in Astoria (around $1,200/month for a share of a 2BR) and literally leaving in the middle of the walk through because the bathroom was so old and gross.

The only (relatively) good deals in Manhattan are in FiDi, where I'd imagine the historical preservation nazis are less nazi-ish about tearing shit down and renovating. At least last time I checked, there was some reasonable new construction/renos down there that didn't cost $5,000/month for a 1BR.

</comment><comment><USER15> From the perspective of a non-NYC resident, this is terrible.

I had understood that bedrooms in the USA had to have a closet and a window/external door. Is that not the case?

<comment><USER16> I'm a recent NYC transplant. In past places I've lived (VA, DC, MN) it's definitely the law that a bedroom must have an egress window — not just a window, but one that opens and is large enough you could exit through it in case of a fire.

In New York, either that _isn't_ the law, or it just gets violated a lot more often. Since moving here I've seen a surprising number of places where the bedroom has no windows.

However, there is definitely no requirement (in any state I've lived in) for a bedroom to have a closet. Some do, many don't.

<comment><USER4> >>>In New York, either that isn't the law, or it just gets violated a lot more often.

That. The city is infested with illegal apartments that would never pass fire inspections.

</comment></comment></comment><comment><USER17> See this Verge article on the NYC renting startup Urban Compass: <http://www.theverge.com/2013/5/7/4304374/urban-compass>

Also, the short book _The Rent Is Too Damn High_ : <http://www.amazon.com/The- Rent-Damn-High-ebook/dp/B0078XGJXO>

These are all very solvable problems, it's just very difficult to change the status quo.

<comment><USER5> There is no hope for NYC on defeating the NIBMY crowed. If I thought there was, I'd personally go around raising money to fight the preservationists.[1]

As corrupt as Chicago is, I do love one thing about it: the corruption sometimes works in peoples' favor. Recently, Northwestern University wanted to tear down its hideous old womens' hospital to put up a new medical facility: [http://d22r54gnmuhwmk.cloudfront.net/photos/1/zg/re/MTzGREji...](http://d22r54gnmuhwmk.cloudfront.net/photos/1/zg/re/MTzGREjiZWtjkHf-556x313-noPad.jpg). The usual suspects bitched about architecture blah blah. Rahm was like "STFU" and Northwestern got a permit to tear that shit down. The funny thing was that they basically abandoned it during the scuffle with the preservationists (like 3-4 years). I'm convinced the plan was to basically be like "oops, looks like it's not safe to occupy anymore!" (buildings break down surprisingly quickly during periods of no occupancy).

[1] I secretly dream of doing a non-profit specializing in litigation against preservationist groups.

<comment><AUTHOR> Is preservation ever good?

<comment><USER5> It's not that preservation is bad, it's that it's rarely subject to any rational cost-benefit analysis. If the EPA promulgates a new regulation, the resulting flood of litigation forces intense scrutiny of the costs and benefits. But nobody has a concentrated interest to stand up to preservationists. An individual developer might oppose it, but existing land- owners as a whole benefit both from the slimmest of historical significance and from keeping down the total supply of office space, housing, etc. So you don't see cities buried in lawsuits over trying to promulgate those sorts of ordinances.

</comment></comment></comment></comment><comment><USER18> Most people in the world do not have this level of luxury in the accommodations. [http://unstats.un.org/unsd/demographic/sconcerns/housing/hou...](http://unstats.un.org/unsd/demographic/sconcerns/housing/housing2.htm) I'm honestly a bit annoyed by this article. Someone wants to live in one of the most populous cities in the world with quite high density and also expects a more luxurious setting and a low price?

<comment><USER4> >>>Someone wants to live in one of the most populous cities in the world with quite high density and also expects a more luxurious setting and a low price?

Yes, because that is how New York City _used to be._ This crap of these illegal one rooms are driven by people who don't give a shit for native New Yorkers or the laws at all.

<comment><USER19> Who the fuck are _native New Yorkers_?

<comment><USER4> People _born_ here. Whose parents were born here. Who made this city. Which is not a goddammed amusement park despite how all the outsiders use it.

<comment><USER6> I'm glad to see _"the immigrants did it"_ is alive and well. /s

<comment><USER4> No, not the immigrants. The Midwesterners.

</comment></comment></comment></comment></comment></comment><comment><USER20> You should look in NJ (specifically Union City, Jersey City, West New York).

I live in Weehawken and spent all my energy looking (for months) in NYC. After living in Astoria (amazing neighborhood) for two and a half years, I decided I wanted more space.

Benefits of living in NJ are: 1) More space 2) Cheaper rent 3) Nicer apartment for the money 4) No NYC residents tax (anywhere from 2-7% depending on income level)

</comment><comment><USER21> I'm paying $1200/month in Houston, but it's 800 sq. ft., newly refurbished hardwood floor, granite counter-tops with kitchen island, new stainless steel appliances, double vanity sinks, rain shower, a little balcony, washer/dryer in unit, and I have a five minute walk to work and also lots of restaurants and night life.

</comment><comment><USER22> This would be a great post. On Reddit.

</comment><comment><USER23> That's sad man. People in NYC are paying what would get you a nice apartment elsewhere for the equivalent of a basement, closet or prison cell. Some of those should be even illegal to rent as residential, no?

</comment><comment><USER24> These are rooms to sleep in. If you think these are that bad, try visiting a real slum. It's first world privilege to consider a small clean room in New York City a horrible place.

<comment><USER25> Yes, and indeed all those pigs tightly packed into the slaughterhouse have food and water and shelter given to them every day, while even today feral swine wander under the harsh elements in search of food and a place to drink.

:/

<comment><USER24> You're missing an essential element: the living conditions of a human in a NYC apartment are _entirely voluntary_.

People rent overpriced tiny places because they can't afford full priced full sized rooms. If overpriced tiny places were not available, full sized rooms would be more expensive and many people would not have the _choice_ to live in a small cheaper room.

Anyway, if you want the real culprit of NYC and SF rental pricing problems, it's very simple: RENT CONTROL IS EVIL. Rent control causes hoarding, and the higher market prices go the more hoarding and the higher prices go. It's a vicious cycle.

</comment></comment></comment><comment> k-mcgrady You must have to really love New York to pay such high prices for places like those. I don't mind living somewhere small and not particularly nice but those places seem terrible.

</comment><comment><USER26> Half the responses in this thread remind me of the _Four Yorkshiremen_ skit:

<http://www.youtube.com/watch?v=Xe1a1wHxTyo>

"Looxereh!"

</comment><comment><USER27> No windows, madness, is the big shitty really all that to suffer solitary confinement...and pay for it to boot?

<comment><USER6> Unlike solitary confinement, you are always free to leave your apartment and enjoy the city. If you rent this sort of apartment then you should be prepared to live a lifestyle that does not involve expecting to be entertained by things that are in your apartment; if you want to do that then you can live _anywhere_ else.

<comment><USER4> >>> If you rent this sort of apartment then you should be prepared to live a lifestyle that

... might include roasting to death due to a fire blocking your only egress.

<comment><USER6> <http://www.nyc.gov/html/om/pdf/2010/2009_fdny_year_end.pdf>

I don't know you, but I can tell you with confidence that you have better things to worry about.

<comment><USER4> Whatever that is, Firefox can't display it. And personally I don't worry. I'm not "living" in one of those cells.

<comment><USER6> It is called a "PDF". It presents data on fire related deaths in New York City. They are practically a rounding error. Congratulations on finding a nicer place to live.

<comment><USER4> I can see it's a damn PDF. Complain to Mozilla that Fox won't display it. And I wasn't about to DL so you could make a point that probably could have been made w/o a PDF.

<comment><USER6> > _Complain to Mozilla that Fox won't display it._

That is probably what you should be doing, not complaining to me.

<comment><USER4> Ha. But I'm not sure I want Firefox to display them.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> This was normal during the housing bubble in almost all the european capitals.

</comment><comment><USER29> Meh.. if you think these are bad, try Copenhagen instead.

</comment><comment><USER30> Even cells in solitary confinement have windows.

<comment><USER31> Comparing these rooms to solitary confinement is pretty stupid. You can't leave solitary confinement whenever you want (hence, "confinement").

<comment><USER21> It might be stupid in most aspects, but many of the cells _do_ have windows.

In many areas of the developed world it's actually illegal to rent out a room without a window.</comment></comment></comment>