• ? (unregistered) in reply to DrCode
    DrCode:
    Of course, in the case of open software like phpBB, they have no choice but to reveal their schema, and the benefits of open source outweigh the down sides.  But even there, if for some reason you really wanted to lock down a phpBB board, it would be a great idea to rename tables and columns or otherwise customize your install, so that an attacker who was otherwise familiar with the system wouldn't be familiar with YOUR system.


    phpBB is probably the worst example you could have chosen. It is full of holes, and more are discovered every couple months.
  • Rich (unregistered) in reply to DrCode
    DrCode:
    Maurits:
    But there are plenty of software systems out there which manage to be secure in spite of public knowledge of both the database schema and the code... phpBB, Community Server, et al.


    You should never rely on security through obscurity, but at the same time, you should aim for defense-in-depth.  The system should be designed to remain secure even if the schema is known; nevertheless, there is no reason to publish the schema if it isn't necessary.

    Remember, security is always about cost/benefit ratios, not about absolute deductive proofs.  Anything you can do to slow down an attacker is a good thing, and you may delay him long enough that his attempts get noticed, or frustrate him enough that he decides to go look for easier targets.

    Of course, in the case of open software like phpBB, they have no choice but to reveal their schema, and the benefits of open source outweigh the down sides.  But even there, if for some reason you really wanted to lock down a phpBB board, it would be a great idea to rename tables and columns or otherwise customize your install, so that an attacker who was otherwise familiar with the system wouldn't be familiar with YOUR system.



    The real problem is that too many people confuse obscurity with security.  I always try to imagine the danger of a 'secret' being known.  If it really would make the system less secure, then the secret had better be protected.  The idea is to really identify which things are secrets, and not to just assume everything is secret.  Actually thinking about what is secret and what is not will make the system more secure.
  • (cs) in reply to ash
    Anonymous:
    versatilia:
    (forgetting the security implications) reminds me of (for fun and pure WTFery) writing mandlebrot generators in Postscript and getting the Laserjet to render it.

    Holy crap. And I thought writing device drivers in a debugger in hex was bad!! I bow before your superiority.


    You can find examples of ... nicely used PostScript on this page.
  • (cs)

    Our school had a system that posted SQL queries in a POST parameter. When two CS students found out about this and reported about the problem, the security hole was promptly filled - the SQL queries were base64 encoded by a little JavaScript. Needless to say, it's now impossible to update your own grades or administratively get rid of a teacher. Yay for "I can't read it, so it's secure!"

  • Welcome To The Machine (unregistered) in reply to the_saint
    the_saint:

    Bugger, I meant "like", or was the the accent.

     

    Obviously the real WTF is the lack of edit.

    You also misspelled caterpillar.

  • (cs) in reply to versatilia
    versatilia:
    (forgetting the security implications) I had a flashback... it's like "let's write our entire logic and presentation code in SQL and let the DB do the work"...

    reminds me of (for fun and pure WTFery) writing mandlebrot generators in Postscript and getting the Laserjet to render it.


    Finally - somebody else who's done this.. A great thing to do after my A levels finished :)

    darj
  • hahanoob (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    Maurits:
    Point taken.

    But there are plenty of software systems out there which manage to be secure in spite of public knowledge of both the database schema and the code... phpBB, Community Server, et al.


    I wish there were more.

    Occasionally, I have read claims that European systems are better than NAm ones.  For example, one-use numbers for charging where the vendor never has the card number but does have something that can be used to make a charge.

    Sincerely,

    Gene Wirchenko



    Stop signing your posts, jesus freaking stop.
  • (cs) in reply to some australian guy
    Anonymous:
    i want wat you guys have been smokin[C][8-)][}][:^)][:@][:-*][B][8-)][Z][D][co][:#][H][:'(][:'(][:$][:$][:$][8-|][au][8o|][8-)]

    What?! We have emoticons on this board?! I thought those things in the left panel were just decorations, nothing happens when they are clicked...
  • Zorro (unregistered) in reply to hahanoob

  • Zorro (unregistered) in reply to hahanoob

    I have to agree, even in these circles it's utterly nerdy.

  • (cs) in reply to Rich
    Anonymous:

    The real problem is that too many people confuse obscurity with security.   I always try to imagine the danger of a 'secret' being known.  If it really would make the system less secure, then the secret had better be protected.  The idea is to really identify which things are secrets, and not to just assume everything is secret.  Actually thinking about what is secret and what is not will make the system more secure.


    actualy...

    technically speaking all security on the internet is based on obscurity in some way. be it keys, passwords or just an url: every form of security or encryption over an open network is based on something you know and others don't.

    the only way to make something secure without obscurity is to make it (theoretically) impossible.

    you don't want to protect your database from injection by someone who is not allowed to change entries. you want to protect your database from injection by _anyone_; including yourself.

    the punchline is that the latter is often easier than the former.
  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:

    Give me your credit card numbers, their expiry dates, and the Xs (whatever the three digit security code is called).


    Wait as second: as far as I understand it, that "three digit security code" should never ever be saved in someone's DB (except the credit card company's, of course). Isn't that the whole point of it? It's checked only once when you first register with a shop, to prevent stolen card numbers being used.
  • (cs) in reply to brazzy

    brazzy:
    Gene Wirchenko:

    Give me your credit card numbers, their expiry dates, and the Xs (whatever the three digit security code is called).


    Wait as second: as far as I understand it, that "three digit security code" should never ever be saved in someone's DB (except the credit card company's, of course). Isn't that the whole point of it? It's checked only once when you first register with a shop, to prevent stolen card numbers being used.

     

    I do wonder about these so called "security" digits.

    Let me explain...

     

    Why is that (well on my car) I have more than three numbers, yet I am only asked to produce the last three - surely instead of 1 in what ever chance, just using the final three makes it down to just a 1 in 1000 chance?

    It may be just me put I for one don't see the logic of this at all!!

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    Occasionally, I have read claims that European systems are better than NAm ones.  For example, one-use numbers for charging where the vendor never has the card number but does have something that can be used to make a charge.


    Sounds like someone mixed stuff up. That's how online banking is done: you have a PIN/password to log into the website, and a list of one-use "transaction numbers" (TAN) that the bank sends you via paper mail, separate from the PIN. For every sensitive transaction you use one TAN. This is mainly used for  money transfers, which is what most people use instead of sending cheques (which is virtually unknown here) or using credit cards.

    But actual credit/debit cards work no different than in the US as far as I know.

    And in fact the PIN/TAN system is not all that secure, it's been targeted/subverted by massive phishing and spyware attacks for some time.
  • (cs) in reply to Cratig
    Cratig:
    Why is that (well on my car) I have more than three numbers, yet I am only asked to produce the last three - surely instead of 1 in what ever chance, just using the final three makes it down to just a 1 in 1000 chance?

    It may be just me put I for one don't see the logic of this at all!!


    Take a close look at the rest of it - it's just the regular CC number, or part of it (well it is, on my Visa and Master cards). And you're already entering that.

    Presumably, the validation system will lock you out after a small number of wrong entries, so that 1/1000 is "good enough".
  • (cs) in reply to brazzy

    Actually thinking about it, I don't think it would be 1/1000.  Let me explain!...

     

    I'm pretty sure that the banks will not allow sequential numbers (ie: 123, 456, 789 etc.) or numbers that are made up of all the same digit (ie: 111, 222, 333 ,444 etc.)

    and I doubt they would allow numbers were to identical digits would sit together ie(114, 422, 800 etc.)  If I'm right, just taking this example off the 1000 combinations would result in 900?

    If that's right, that would be 900 less 10 for the numbers with all same digits (don't forget the zeros!!) so that's 890

    Then take away the sequential numbers, 012 123 234 456 567 789 890 901, that's 8 so then 890 becomes 882

    And I'm also guessing that the bank won't allow the security digit to be the same as the last three digits of the card number, so that's another 1 to take off.

    So we are left with 881 combinations.  I'm no math genious, but I'm guessing that there are other combinations of numbers that should be removed too, although I can't think of any right now!

  • svip (unregistered) in reply to Cratig

    This whole deal makes me think of the argument I had with my lecturer earlier today - at an exam of all things.

    He insisted that the simple game I'd made would've been much better if the client decided whose turn it is to move, what the correct answer was, etc.

    At least any of my co-students that listen to him can supply us with WTF's someday.

  • (cs) in reply to Gene Wirchenko

    Gene Wirchenko:
    Occasionally, I have read claims that European systems are better than NAm ones.  For example, one-use numbers for charging where the vendor never has the card number but does have something that can be used to make a charge.

    Oh, that's a "EU" thing?  I've got that with my card right here in the good ol' US of A.

  • Anders Isaksson (unregistered) in reply to brazzy

    No mix-up at all. When I want to use my bank card (with Visa) on the internet, I run a small app from my bank, which generates a one-time 'card' with selectable amount of money and expiration month. Every transaction is done on a unique 'card' with a very limited amount of money.

  • Anders Isaksson (unregistered) in reply to brazzy
    brazzy:
    Gene Wirchenko:
    Occasionally, I have read claims that European systems are better than NAm ones.  For example, one-use numbers for charging where the vendor never has the card number but does have something that can be used to make a charge.


    Sounds like someone mixed stuff up. That's how online banking is done: you have a PIN/password to log into the website, and a list of one-use "transaction numbers" (TAN) that the bank sends you via paper mail, separate from the PIN. For every sensitive transaction you use one TAN. This is mainly used for  money transfers, which is what most people use instead of sending cheques (which is virtually unknown here) or using credit cards.

    But actual credit/debit cards work no different than in the US as far as I know.

    And in fact the PIN/TAN system is not all that secure, it's been targeted/subverted by massive phishing and spyware attacks for some time.


    [image]
    No mix-up at all. When I want to use my bank card (with Visa) on the internet, I run a small app from my bank, which generates a one-time 'card' with selectable amount of money and expiration month. Every transaction is done on a unique 'card' with a very limited amount of money.
    (Located in Sweden, BTW)

  • me (unregistered) in reply to Cratig
    Cratig:
    I'm pretty sure that the banks will not allow sequential numbers (ie: 123, 456, 789 etc.) or numbers that are made up of all the same digit (ie: 111, 222, 333 ,444 etc.)


    I had a card once with a sequential CVV3 code.
  • Vince P (unregistered) in reply to ChiefCrazyTalk

    Anonymous:
    Anonymous:
    Brillant!
    You said it, Paula!

     

    I love the PaulaBean

  • (cs) in reply to Anders Isaksson
    Anonymous:
    No mix-up at all. When I want to use my bank card (with Visa) on the internet, I run a small app from my bank, which generates a one-time 'card' with selectable amount of money and expiration month. Every transaction is done on a unique 'card' with a very limited amount of money.


    Do you have details?  A URL would be great.

    Sincerely,

    Gene Wirchenko

  • I hope my boss doesn't see this... (unregistered) in reply to brazzy
    brazzy:
    Gene Wirchenko:

    Give me your credit card numbers, their expiry dates, and the Xs (whatever the three digit security code is called).


    Wait as second: as far as I understand it, that "three digit security code" should never ever be saved in someone's DB (except the credit card company's, of course). Isn't that the whole point of it? It's checked only once when you first register with a shop, to prevent stolen card numbers being used.


    Yes, that is the point of the CV2 code, but sadly not everyone cares.  For example, where I work we store this code in the db to make it harder for our customers to dispute charges on automated monthly orders (yes, I work for a fucked up company).  We still managed to get 'certified' by visa by lying about this...
  • I hope my boss doesn't see this... (unregistered) in reply to me

    Anonymous:
    Cratig:
    I'm pretty sure that the banks will not allow sequential numbers (ie: 123, 456, 789 etc.) or numbers that are made up of all the same digit (ie: 111, 222, 333 ,444 etc.)


    I had a card once with a sequential CVV3 code.

    The code on my old card was 555...

     

  • (cs) in reply to Gene Wirchenko

    Gene Wirchenko:
    Anonymous:
    No mix-up at all. When I want to use my bank card (with Visa) on the internet, I run a small app from my bank, which generates a one-time 'card' with selectable amount of money and expiration month. Every transaction is done on a unique 'card' with a very limited amount of money.


    Do you have details?  A URL would be great.

    Sincerely,

    Gene Wirchenko

    Here's a link to the Citibank site with a description.  Presumably other providers have something similar.

    http://www.citibank.com/us/cards/tour/cb/shp_van.htm

     

  • (cs) in reply to Cratig
    Cratig:

    Actually thinking about it, I don't think it would be 1/1000.  Let me explain!...

     

    I'm pretty sure that the banks will not allow sequential numbers (ie: 123, 456, 789 etc.) or numbers that are made up of all the same digit (ie: 111, 222, 333 ,444 etc.)

    and I doubt they would allow numbers were to identical digits would sit together ie(114, 422, 800 etc.)  If I'm right, just taking this example off the 1000 combinations would result in 900?

    If that's right, that would be 900 less 10 for the numbers with all same digits (don't forget the zeros!!) so that's 890

    Then take away the sequential numbers, 012 123 234 456 567 789 890 901, that's 8 so then 890 becomes 882

    And I'm also guessing that the bank won't allow the security digit to be the same as the last three digits of the card number, so that's another 1 to take off.

    So we are left with 881 combinations.  I'm no math genious, but I'm guessing that there are other combinations of numbers that should be removed too, although I can't think of any right now!



    Um... you've just pointed out yourself that disallowing certain number combinations would in fact make the system LESS secure. So why should the CC company do it?

    You disallow too-simple passwords because the users choose them themselves  and, given the chance, will choose easy to remember (usually too-simple) ones, which the attackers know and try first. But since those numbers are assigned at random, rather than chosen by the user, there is no advantage for the attacker in trying certain patterns first, and thus, also no advantage for the CC company in avoiding them.

    Do you also believe that in a lottery that allows you to choose your number, choosing sequential numbers makes it less likely to win? Or more likely?
  • Anonymous (unregistered) in reply to akrotkov
    akrotkov:
    Anonymous:

    If strSortBy & "" <> "" Then

    <font size="2">I like that part a lot too, I mean, "Take strSortBy and nothing and compare it to nothing, if it matches then don't go on."</font>



    That's actually a quick and dirty method of converting to a string - concatenate a null string to it.

    Same as (in java)

    String numToInt = i + "";

    well, these comments are rubbish when talking about java. "test" + null results in "testnull" and the correct way to convert any number to String is String.valueOf(). concatenating the empty string to a number in java is awful.

  • (cs) in reply to ?
    Anonymous:
    phpBB is probably the worst example you could have chosen. It is full of holes, and more are discovered every couple months.


    http://www.openbsd.org/ .

    OpenBSD would be a better example. They claim "Only one remote hole in the default install, in more than 8 years!". However given that the default install does not contain any/many network services take it with a grain of NaCl.
  • (cs) in reply to GalacticCowboy
    GalacticCowboy:
    Gene Wirchenko:
    Anonymous:
    No mix-up at all. When I want to use my bank card (with Visa) on the internet, I run a small app from my bank, which generates a one-time 'card' with selectable amount of money and expiration month. Every transaction is done on a unique 'card' with a very limited amount of money.

    Do you have details?  A URL would be great.

    Here's a link to the Citibank site with a description.  Presumably other providers have something similar.

    http://www.citibank.com/us/cards/tour/cb/shp_van.htm

    Light reading, but now, I have a search term.  Thank you.

    Sincerely,

    Gene Wirchenko

  • Sum Fag (unregistered) in reply to d
    Anonymous:
    Maurits:
    If CallQuery.asp is really running whatever cookie is in the SQL, then THAT is the WTF.  Not only is it a SQL injection attack, but consider what happens when a user:

    1) Calls up one report
    2) Calls up another report on different criteria (changing the cookie)
    3) Refreshes the first report - the page now shows the second report!

    If the page is named CallQuery.asp, that does seem likely...

    As to the exposure of the internal data model to SQL injection attacks... that doesn't overly concern me.  Security through obscurity is no security at all. A SQL injection attack can be used to query the system catalogs anyway and enumerate the tables, their fields, the text of stored procedures (unless encrypted,) etc.


    Good point, I guess dropping the db isn't that bad as long as the dba is backing his junk up.  Having some hack extract all the contents of a db is pretty dangerous especially if it contains my credit card info.

    (captcha  'dinky' rofl)


    Do you monkeys know that the DB-user has perhaps only read-access? Good luck dropping/changing/whatever with read-only privileges, morons.
  • (cs) in reply to Sum Fag
    Anonymous:


    Do you monkeys know that the DB-user has perhaps only read-access? Good luck dropping/changing/whatever with read-only privileges, morons.

    Oh no.  It was logging in as sa.  This was in the provided summary.
  • (cs) in reply to Sum Fag
    Anonymous:
    Do you monkeys know that the DB-user has perhaps only read-access? Good luck dropping/changing/whatever with read-only privileges, morons.


    Tsk, tsk!  Your manners are lacking.

    No, we do not know, but given a design as bad as this, it is quite possible, and arguably likely, that access restrictions have not been considered.  I have seen networks where the only user id used is the root one.

    Sincerely,

    Gene Wirchenko

  • Rich (unregistered) in reply to lukas
    lukas:
    Anonymous:

    The real problem is that too many people confuse obscurity with security.   I always try to imagine the danger of a 'secret' being known.  If it really would make the system less secure, then the secret had better be protected.  The idea is to really identify which things are secrets, and not to just assume everything is secret.  Actually thinking about what is secret and what is not will make the system more secure.


    actualy...

    technically speaking all security on the internet is based on obscurity in some way. be it keys, passwords or just an url: every form of security or encryption over an open network is based on something you know and others don't.

    the only way to make something secure without obscurity is to make it (theoretically) impossible.

    you don't want to protect your database from injection by someone who is not allowed to change entries. you want to protect your database from injection by _anyone_; including yourself.

    the punchline is that the latter is often easier than the former.


    No...

    You're confusing secrecy with obscurity.

    Obscurity is 'hiding' your password as some complex operation in your program, assuming (incorrectly) that nobody is smart enough or dedicated enough to sit down with a disassembler and debugger and find it.

    Secrecy is not putting your password in the program in the first place.

    Obscurity is writing your password on the postit backwards.  Secrecy is not writing your password on a postit.

    A secret is something an attacker can only reasonably discover through brute force.  Obscurity is something an attacker could figure out through other means.

  • (cs) in reply to Rich

    Anonymous:
    lukas:
    Anonymous:

    The real problem is that too many people confuse obscurity with security.   I always try to imagine the danger of a 'secret' being known.  If it really would make the system less secure, then the secret had better be protected.  The idea is to really identify which things are secrets, and not to just assume everything is secret.  Actually thinking about what is secret and what is not will make the system more secure.


    actualy...

    technically speaking all security on the internet is based on obscurity in some way. be it keys, passwords or just an url: every form of security or encryption over an open network is based on something you know and others don't.

    the only way to make something secure without obscurity is to make it (theoretically) impossible.

    you don't want to protect your database from injection by someone who is not allowed to change entries. you want to protect your database from injection by _anyone_; including yourself.

    the punchline is that the latter is often easier than the former.


    No...

    You're confusing secrecy with obscurity.

    Obscurity is 'hiding' your password as some complex operation in your program, assuming (incorrectly) that nobody is smart enough or dedicated enough to sit down with a disassembler and debugger and find it.

    Secrecy is not putting your password in the program in the first place.

    Obscurity is writing your password on the postit backwards.  Secrecy is not writing your password on a postit.

    A secret is something an attacker can only reasonably discover through brute force.  Obscurity is something an attacker could figure out through other means.

    A Secret remains a Secret until detected. At which point it simply becomes an Obscurity waiting for clarity. The obvious can be a secret sans observation. The biggest risk to a secret is the number of observations it has to endure.

  • Anders Isaksson (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    Do you have details?  A URL would be great.


    http://www.fsb.se/sst/inf/out/infOutWww/0,,46267,00.html
  • (cs) in reply to Rich
    Anonymous:

    No...

    You're confusing secrecy with obscurity.

    Obscurity is 'hiding' your password as some complex operation in your program, assuming (incorrectly) that nobody is smart enough or dedicated enough to sit down with a disassembler and debugger and find it.

    Secrecy is not putting your password in the program in the first place.

    Obscurity is writing your password on the postit backwards.  Secrecy is not writing your password on a postit.


    no, i'm saying that in an open network like the internet there is no such thing as what you call secrecy. there is no way to refrain from writing something (maybe not the thing itself, but something) down if you want to use it in your program in some way. the only way to keep it secret is to not write it down.


    "login failed: your password could not be verified (because we didn't save it anywhere for security reasons)." (haha, just kidding)


    what you mean to say (i think) is that you should not put the plaintext password somewhere hidden away, but use some sort of 'one-way' algorithm to code it (MD5 perhaps). then, even when the user-database is compromised, the data is still (marginally) safe, because the user-database can only be used to verify a given password, not to find the password itself (except by brute force of course).


    if that is what you are saying, i agree.

    Anonymous:

    A secret is something an attacker can only reasonably discover through brute force.  Obscurity is something an attacker could figure out through other means.


    if you're implying that the attacker can never know the secret while you can; then imho secrets do not exist as far as the internet is concerned. that is what i meant when i said "the only way to make something secure without obscurity is to make it (theoretically) impossible".

    in the passwords example: the only way to keep your password a secret is to make it impossible for _anyone_ (including yourself) to read it easily (e.g. MD5).
  • Rich (unregistered) in reply to lukas
    lukas:
    Anonymous:

    No...

    You're confusing secrecy with obscurity.

    Obscurity is 'hiding' your password as some complex operation in your program, assuming (incorrectly) that nobody is smart enough or dedicated enough to sit down with a disassembler and debugger and find it.

    Secrecy is not putting your password in the program in the first place.

    Obscurity is writing your password on the postit backwards.  Secrecy is not writing your password on a postit.


    no, i'm saying that in an open network like the internet there is no such thing as what you call secrecy. there is no way to refrain from writing something (maybe not the thing itself, but something) down if you want to use it in your program in some way. the only way to keep it secret is to not write it down.


    "login failed: your password could not be verified (because we didn't save it anywhere for security reasons)." (haha, just kidding)


    what you mean to say (i think) is that you should not put the plaintext password somewhere hidden away, but use some sort of 'one-way' algorithm to code it (MD5 perhaps). then, even when the user-database is compromised, the data is still (marginally) safe, because the user-database can only be used to verify a given password, not to find the password itself (except by brute force of course).


    if that is what you are saying, i agree.

    Anonymous:

    A secret is something an attacker can only reasonably discover through brute force.  Obscurity is something an attacker could figure out through other means.



    if you're implying that the attacker can never know the secret while you can; then imho secrets do not exist as far as the internet is concerned. that is what i meant when i said "the only way to make something secure without obscurity is to make it (theoretically) impossible".

    in the passwords example: the only way to keep your password a secret is to make it impossible for _anyone_ (including yourself) to read it easily (e.g. MD5).


    I'm  just saying that 'secret' and 'obscure' are well understood security terms, and 'secret' != 'really really obscure'.  When I type in my plaintext password and sent it via SSL to a remote website, I don't think my password is obscure, it's a secret, with regard to an attacker.  The remote web site is obviously not an attacker.  If they have some rouge employee sniffing passwords between their web site and DB, well, that's another matter.

    I don't think a password has to be unreadable even to myself to be secret.  It just has to be something that an attacker can't discover and use.  In fact, I can write it down and still have it be secret, as long as I e.g. put it in my safe and lock it.  Yes, an attacker can open my safe, just like they can brute force my password.

    In fact, wether I type in a plaintext password or MD5 password is irrelevent.  At that point, the MD5 version becomes the password.  Whatever I type in is the secret.

  • tim (unregistered) in reply to Rich

    i had a guid for a password once. after about a month I remembered it. But nobody else could, even if I told it to them (and sometimes even if I wrote it down).

  • (cs) in reply to Rich
    Anonymous:

    I'm  just saying that 'secret' and 'obscure' are well understood security terms, and 'secret' != 'really really obscure'.  When I type in my plaintext password and sent it via SSL to a remote website, I don't think my password is obscure, it's a secret, with regard to an attacker.  The remote web site is obviously not an attacker.  If they have some rouge employee sniffing passwords between their web site and DB, well, that's another matter.

    I don't think a password has to be unreadable even to myself to be secret.  It just has to be something that an attacker can't discover and use.  In fact, I can write it down and still have it be secret, as long as I e.g. put it in my safe and lock it.  Yes, an attacker can open my safe, just like they can brute force my password.

    In fact, wether I type in a plaintext password or MD5 password is irrelevent.  At that point, the MD5 version becomes the password.  Whatever I type in is the secret.


    Yes, i agree. but the problem is that humans make mistakes (well, not _us_ of course, but them) and that the open network is made by different humans (not only us, but also people like the person who wrote the code that started this post).

    the second problem is that we both have different ideas about what is secret. also we think differently about comping. me being an annoying student who thinks about computers only in a theoretical sense, not the practical :)

    you state that a secret is something an 'attacker' cannot know by ay other means than brute force. imho you can never rely on something being such a secret; simply because of the fact that you will never write the whole system yourself and people like the person who wrote the code above will write at least some part of the system.

    i was trying to protect the system against hackers and worthless programmers.

    as far as MD5 is concerned: you would type in your normal password and the server will translate it using MD5 to check it against the database records. so the same precautions should be in effect when transporting the password over the internet (SSL is a good idea, yes).

    the point with MD5 translations of passwords in the database in stead of plaintext is that if someone puts a piece of shit code like the above on the same server as your userdb (he was logging in as sa, right?) and some hacker gets into the database using mySQL-injection, the data will be useless to him.

    sorry for being such an ass, btw. i just love a good argument.

  • Rich (unregistered) in reply to lukas
    lukas:


    Yes, i agree. but the problem is that humans make mistakes (well, not _us_ of course, but them) and that the open network is made by different humans (not only us, but also people like the person who wrote the code that started this post).

    the second problem is that we both have different ideas about what is secret. also we think differently about comping. me being an annoying student who thinks about computers only in a theoretical sense, not the practical :)


    Actually, it seems to me that you're coming at it more from a practical sense, and I a theoretical (idealistic?) sense.

    lukas:

    you state that a secret is something an 'attacker' cannot know by ay other means than brute force. imho you can never rely on something being such a secret; simply because of the fact that you will never write the whole system yourself and people like the person who wrote the code above will write at least some part of the system.

    i was trying to protect the system against hackers and worthless programmers.

    as far as MD5 is concerned: you would type in your normal password and the server will translate it using MD5 to check it against the database records. so the same precautions should be in effect when transporting the password over the internet (SSL is a good idea, yes).

    the point with MD5 translations of passwords in the database in stead of plaintext is that if someone puts a piece of shit code like the above on the same server as your userdb (he was logging in as sa, right?) and some hacker gets into the database using mySQL-injection, the data will be useless to him.

    sorry for being such an ass, btw. i just love a good argument.



    You're not an ass in the slightest.  We're both just arguing semantics.  But discussions/arguments which hash (no pun intended) out these details are extremely important to the process.  Nobody is ever always right.

  • david (unregistered)

    I've never seen anything like it. If I ever have grandchildren, and I'm still alive to tell them stories, I hope I'll be able to recall this moment.

Leave a comment on “Toss Your Cookies Round 'n' Round”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article