A hack proof website is one which is only static html pages, with no processing on the server side...

The website itself couldn't ever be hacked then, but the server software or os could be, this is a different kettle of fish. You can mitigate this by unloading every cgi like module and unused feature from your Web server software, and only running the Web server software and no other daemon at all.

And yes, there are tons of useful html only websites even in 2015...

All of this is still "hacking a website", wether you do it through the OS or the web server the end result is the same, you can take the website down, you can get the website source, you can change the website content, the website is hacked.

1) yes which is why there are 2 discutions in parallel, my use case which is pretty easy to secure, and the generic website use case which i still believe is possible but is definately not quite as simple nor black and white.

2) it's not a typical business model at all, basically none of those customers are mine to begin with but i don't want to enter into détails here, but for simplity's sake just assume it's the type of 1 time end user purchase where there's pretty much no hope of making a second purchase and that works on the volume of people ordering. A quite silly example would be purchasing a casquet for your funeral, you're unlikely to buy another one, ok it's not the same here but it's very likely around 1% of our customers at most would be returning customers, and probably 1% of that 1% would return more than once.

3) You can't really "guess" it except by brute force, and there's no value in it anyway, basically it would take a LOT of effort to get ONE url right and all you'd get is a model of someone (you don't know who) out of a million. There's Nothing wrong with that, Dropbox urls are much shorter than 2000 character long and are widly used. Once again this is not Customer bank account detail it gives you access to, it gives you something that is "really" not sensitive. And i still do my best to secure it but it's NOT possible to secure what goes on the net (data you transmit) and it's NOT my business to do it (i can't secure end user email accounts that are out of my controls, or the routers of their isps), my job is only to try and keep their data private within the limits of my network and doing that by sending them an url with 64 power 2000 possible combinations seems . . . fairly safe, but once again this is for argument's sake, it is NOT the part i claim can be fully secured, i'm just answering to that since you bring it up. For comparison (the filename aside) dropbox's randomly generated size is 15 characters when you create a link to share, and a link to share is exactly what we send to the customer, except 64 pow 2000 is quite a bit more than 64 (or 255 or whatever they use) pow 15

4) What we do hasn't been done before but as i said i'm not ready to announce it yet. It is sufficiently different to be very valuable and it's not simply photogrammetry, if you're that curious pm me i won't say much more but the little more i'll say will help understand why there's value to protect.

You missunderstand how i treat my customer assets, i secure them the best i can, but just like any business i put "more" work on the critical parts that are securable than on the public part that by definition can't be fully secured.

The internet ate my response, so I'll keep this retry short...

My post was not meant as an attack on your or your business idea. With the limited information you can give me, I am in no position to really make the call there...

Also I think I can agree 100% to your last sentence. Invest into security where it matters, invest into risk mitigation where security is not possible or becomes overly expensive.

I wouldn't dismiss brute force attacks altogether. Thanks to programmable GPUs, brute forcing has become viable again. Altough a 2000 character string is in a different league to the usual 128-bit encryption brute force attacks target usually.

If your site really is a prime target for hackers IDK... most probably not.

1) yes which is why there are 2 discutions in parallel, my use case which is pretty easy to secure, and the generic website use case which i still believe is possible but is definately not quite as simple nor black and white.

2) it's not a typical business model at all, basically none of those customers are mine to begin with but i don't want to enter into détails here, but for simplity's sake just assume it's the type of 1 time end user purchase where there's pretty much no hope of making a second purchase and that works on the volume of people ordering. A quite silly example would be purchasing a casquet for your funeral, you're unlikely to buy another one, ok it's not the same here but it's very likely around 1% of our customers at most would be returning customers, and probably 1% of that 1% would return more than once.

3) You can't really "guess" it except by brute force, and there's no value in it anyway, basically it would take a LOT of effort to get ONE url right and all you'd get is a model of someone (you don't know who) out of a million. There's Nothing wrong with that, Dropbox urls are much shorter than 2000 character long and are widly used. Once again this is not Customer bank account detail it gives you access to, it gives you something that is "really" not sensitive. And i still do my best to secure it but it's NOT possible to secure what goes on the net (data you transmit) and it's NOT my business to do it (i can't secure end user email accounts that are out of my controls, or the routers of their isps), my job is only to try and keep their data private within the limits of my network and doing that by sending them an url with 64 power 2000 possible combinations seems . . . fairly safe, but once again this is for argument's sake, it is NOT the part i claim can be fully secured, i'm just answering to that since you bring it up. For comparison (the filename aside) dropbox's randomly generated size is 15 characters when you create a link to share, and a link to share is exactly what we send to the customer, except 64 pow 2000 is quite a bit more than 64 (or 255 or whatever they use) pow 15

4) What we do hasn't been done before but as i said i'm not ready to announce it yet. It is sufficiently different to be very valuable and it's not simply photogrammetry, if you're that curious pm me i won't say much more but the little more i'll say will help understand why there's value to protect.

You missunderstand how i treat my customer assets, i secure them the best i can, but just like any business i put "more" work on the critical parts that are securable than on the public part that by definition can't be fully secured.

The internet ate my response, so I'll keep this retry short...

My post was not meant as an attack on your or your business idea. With the limited information you can give me, I am in no position to really make the call there...

Also I think I can agree 100% to your last sentence. Invest into security where it matters, invest into risk mitigation where security is not possible or becomes overly expensive.

I wouldn't dismiss brute force attacks altogether. Thanks to programmable GPUs, brute forcing has become viable again. Altough a 2000 character string is in a different league to the usual 128-bit encryption brute force attacks target usually.

If your site really is a prime target for hackers IDK... most probably not.

I don't think it's a prime target for hackers, nor a target at all, but it may be a target for "cheap" industrial espionage, definately not for Something on the scale required to get to it however.

Programmable GPU don't help at all on brute forcing Something remotely, if you have physical access to Something then you can brute force (well, not quite so simple but let's assume you can). However with remote calls a GPU won't help, it's not hard at all to "generate" the sequence of all 64pow2000 sequences that are 2000 characters long in a set using 64 characters, however it's not like cracking a password, you can't just keep doing it untill you get an expected output here, it's easy to limit retries (even on valid queries), even if i set a max to Something crazy high for a human user (5 tries / second / ip) and you attack it remotely with a botnet of 1 000 000 bots at full speed you're only trying 5 000 000 strings / second or less than 450 billion / day. Just to be clear as sometimes numbers are clearer than powers to visualize (i hope this will go through while posting . . .).

Everyday hammering the service (assuming it could answer that fast) you'd have 450 000 000 000 / 64E2000 or 1/(64E2000/450 000 000 000) chance per day to find the one set you're looking for. Even if you're looking for any set and assuming my company is very sucessfull and ends up with 20 million sets that's still only 20 000 000 more chance to get "one" set per day or 1/(64E2000/(450 000 000 000 * 20 000 000)) = a daily chance of 1 over . . . .

Yea, that won't happen

I would personally recommend against using a 2000-character "key" in the URL. While it is without any doubt impossible to guess, it is also one of the things that will instantly cause anyone with a security-related background to assume that you have no profound understanding of the matter, and shout at you accordingly. You're losing a lot of credibility doing that (in addition to using the word "unhackable").

42 radix-64 characters are equivalent to a work factor of 2256, which is commonly agreed to be thermodynamically impossible to brute-force, even assuming an ideal computer. That means that using 50 or 60 radix-64 characters, let alone 2,000 of them, is entirely meaningless. Even more so as an online attack is as far from an ideal computer as it can possibly be.

Do something reasonable, use 42 characters (32 would be enough, too -- that's still a 2192 workload). Or 50 if you really feel like going all paranoia. But never 2,000.

Not really no. I know it's by far overkill (my post should make that clear), there are other reasons for making it long that are unrelated to guessability and there's no drawback at all to making it longer, there's pretty much 0 cost to generating / storing those keys. If you read the thread you'll see the claim of unhackability have 0 Relationship with this key nor even the data it protects but to the exe in ram once again, i was just answering to the question about that risk but yes that risk would be close to 0 even with a massively shorter identifier.

64^2000 = 2^16000. Overkill.

Why exactly are you using the URL for anything related to security? Do you not have a credentials based log-in session setup? /TheClearAndEasyToUnderstandFileName or just /YourFiles is a whole lot cleaner and easier to deal with from a user's standpoint.

Why exactly are you using the URL for anything related to security? Do you not have a credentials based log-in session setup? /TheClearAndEasyToUnderstandFileName or just /YourFiles is a whole lot cleaner and easier to deal with from a user's standpoint.

I guess that is already answered by ronan.thibault: his server should not contain any user data at all:

We don't really store "Customer data", what can be hacked (not on our system, but outside as it transit on the net) are actual 3D models generated from sets of pictures of a given person, those are pretty much uninteresting except for the given person.

So I guess he intends to use the URL to contain such session information (how exactly he handles session failures like browser crashes and so on without the customer loosing access to the generated model IDK, but he mentioned that he only described the service and how it works in parts, which is understandable)...

Why exactly are you using the URL for anything related to security? Do you not have a credentials based log-in session setup? /TheClearAndEasyToUnderstandFileName or just /YourFiles is a whole lot cleaner and easier to deal with from a user's standpoint.

Heh. This reminds me of a honey pot I put in several of my sites. Embedded deep inside is a plaintext string in a url request that looks like sql. It's only purpose is to be checked for changes and is in no way part of the database code. If it's been changed the curious person trying to tweak it ends up temporary firewalled and an email alert comes to me...

Heh. This reminds me of a honey pot I put in several of my sites. Embedded deep inside is a plaintext string in a url request that looks like sql. It's only purpose is to be checked for changes and is in no way part of the database code. If it's been changed the curious person trying to tweak it ends up temporary firewalled and an email alert comes to me...

Did it ever get triggered?