Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things you should do now (2011)

secure.phabricator.com

Post reply on HN
Print view View original

21–30 of 115 posts

Re: Things you should do now (2011)

#21

Post by thomasahle »

corty wrote: post #18
adrianN wrote: post #15

Earlier quoted context omitted.

This topic is pretty close to flamebait so it gets downvoted would be my guess.

Yes, but why? How? I'm a non-native-speaker as well, and these things might be obvious to you, but they aren't to me. Is it a "should not use it", "must not use it", "maybe" or "it's fashionable"? How bad would it be if I accidentially use it, more like a four-letter-word or more like "well, he's a foreigner, he doesn't know"?

That's the problem with flamewars. You can't really recommend in any direction without baiting the flames. You'll just have to look for previous discussions and decide for yourself.

Re: Things you should do now (2011)

#22

Post by genezeta »

bryanrasmussen wrote: post #2

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

Not bugs but I've encountered a consequence which is worse than a bug.

In a recent project I arrived at, I started seeing 612 in random places in the code. It was, naturally, the ID of a very specific user. Having an easy ID to remember, it is a temptation for sloppy programmers to just hardcode certain checks against a particular ID instead of following proper procedures. It was a bad project and a bad team, and after some 10 years or so, the code was now flooded with 612 and a couple of other IDs.

Sure, you could avoid such a thing with code revisions and such, but then again it's better to simply not put the temptation in front of the programmers, isn't it?

Re: Things you should do now (2011)

#23

Post by ozim »

Cthulhu_ wrote: post #7
tpetry wrote: post #6

Earlier quoted context omitted.

A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.

My main gripe with UUIDs at the moment is that they look ugly in urls :/

You should not use your database identifiers in urls anyway.

Re: Things you should do now (2011)

#24

Post by codingdave »

tpetry wrote: post #6
bryanrasmussen wrote: post #2

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.

If you are implying that having an un-guessable URL secures your data, you might want to reconsider that approach. Your data should be secured server-side based on the actual auth in your app.

Re: Things you should do now (2011)

#25

Post by [deleted] »

genezeta wrote: post #22
bryanrasmussen wrote: post #2

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

Not bugs but I've encountered a consequence which is worse than a bug. In a recent project I arrived at, I started seeing 612 in random places in the code. It was, naturally, the ID of a very specific user. Having an easy ID to remember, it is a temptation for sloppy programmers to just hardcode certain checks against a particular ID instead of following proper procedures. It was a bad project and a bad team, and aft…

[deleted]

Re: Things you should do now (2011)

#27

Post by dkarp »

mherrmann wrote: post #26
marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

What's wrong with integer IDs?

The main issue in my experience are so called "user enumeration attacks", especially with sequential ids that are normally used.

This is where an attacker is able to leak information from your system just by guessing ids. If you used a sequential id then you can cycle from 1 to X and probably easily find which are valid users. You can then likely see how many valid users/ids there are and potentially pull their data if the authentication has been implemented incorrectly.

By using a UUID, the key space is so large that you cannot reasonably guess user ids. So you can't use those same brute force techniques and it makes extricating data much harder.

Re: Things you should do now (2011)

#28

Post by dkarp »

marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces.

Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

Re: Things you should do now (2011)

#29

Post by blacktriangle »

dkarp wrote: post #28
marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

I've run into one, but it was pretty dumb. Multitenant application using the account ID as the first element in the URL on a Rails app. when it got to account 404, my address.com/404 went to the static 404 page rather than account 404. That user was pretty confused for awhile.

Re: Things you should do now (2011)

#30

Post by chromatin »

dkarp wrote: post #28
marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

The reason (other than "don't expose integer PK externally") people say you should use integer as PK and UUID as a secondary/external facing id is that conventional B-tree indexing of UUID is not as efficient as B-tree indexing of autoinc integers in most databases.

However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square one.

I choose to forego the integer PK and just use UUID since I have to create index over it anyway.

Post reply on HN