Results 121 to 150 of 213
Thread: Programmers in the Playground
-
2015-06-05, 01:57 PM (ISO 8601)
- Join Date
- Aug 2009
- Location
- Maryland
- Gender
Re: Programmers in the Playground
That just requires further steps to mitm it. *shrug* The whole point of mitm is that you're grabbing everything, and then passing it on. You don't need the password per se if you have access.
And that's leaving aside the possibility of determining the key from many hashes of known text, which should grow with reuse.
-
2015-06-05, 03:22 PM (ISO 8601)
- Join Date
- Jun 2007
- Location
- Non Sequitoria
- Gender
Re: Programmers in the Playground
There's a reason I haven't gotten too deep into security. Mostly it's that I just haven't gotten around to it. But it is rather challenging.
Suppose since I'm here any recommendations on reading material and other resources?Spoiler
Rizban: You could be all, "Today's Destruction is brought to you by the color green.... I HATE GREEN!" then fly off mumbling to yourself "Seven... seven bats... mwa ha ha ha..."
Don't mind me. I'm just going to have some post traumatic flashbacks in the corner here and sob uncontrollably.
Millenium Earl by Shmee
-
2015-06-05, 03:34 PM (ISO 8601)
- Join Date
- Feb 2013
- Location
- Prime Material Plane
- Gender
Re: Programmers in the Playground
Damn, good point. I suppose that I could store the actual hash of the password in the cookies, but then an attacker who packet sniffs as you pointed out would just be able to set the cookies on their machine to match up with the password hash that they got. Hopefully it would be better than simply storing the password in a plaintext cookie though.
-
2015-06-05, 06:27 PM (ISO 8601)
- Join Date
- Feb 2009
- Location
- A nice, sparkly place.
- Gender
Re: Programmers in the Playground
Anyone here experience in programming in Unix in the language of Perl? I have a computer project that I have to put together in a week where the rest of my class gets 2 weeks because I have to leave for the final week of the term and have to get all my finals and projects done a week early. If someone here knows how to program in Perl that can help me along in finishing my project in time, that would be EXTREMEMLY helpful.
-
2015-06-06, 01:26 AM (ISO 8601)
- Join Date
- Feb 2007
- Location
- Manchester, UK
- Gender
Re: Programmers in the Playground
The point is, though, you can't just take the first password hash you intercept and use it to gain access to the system, because the second time a login is attempted a different challenge will be generated, requiring a different hash in reply. Yes, it might be possible to figure out the key from analysing logins, but if the hashes are cryptographically secure and the challenge is properly random then it will take a heck of a lot of them to do this--and since people don't usually log in more than a few times a day, you don't have a lot of data to work with. It could take months or even years to figure out the password via your MITM attack, and 99% of hackers don't have the time or the inclination to spend that long trying to crack a single system.
-
2015-06-07, 05:04 PM (ISO 8601)
- Join Date
- Jun 2007
- Location
- Non Sequitoria
- Gender
Re: Programmers in the Playground
I think that the number of people reading this thread is fairly small. I'd suggest you keep looking. Ideally what you're looking for is something along the lines of a perl IRC. As you look for communities, read assorted tutorials and documentation. You'll want to skip the stuff you already know since there's a time constraint and all.
I'm not all that great when it comes to learning languages as I tend to go all out. Read things like crazy when the more important thing to do is sit down and start writing code.Spoiler
Rizban: You could be all, "Today's Destruction is brought to you by the color green.... I HATE GREEN!" then fly off mumbling to yourself "Seven... seven bats... mwa ha ha ha..."
Don't mind me. I'm just going to have some post traumatic flashbacks in the corner here and sob uncontrollably.
Millenium Earl by Shmee
-
2015-06-09, 12:14 PM (ISO 8601)
- Join Date
- Jan 2006
- Location
- UK
- Gender
-
2015-06-09, 02:55 PM (ISO 8601)
- Join Date
- Aug 2010
Re: Programmers in the Playground
I did a ton of perl, about 15 years ago :) I may or may not have useful advice.
-
2015-06-09, 03:07 PM (ISO 8601)
- Join Date
- Dec 2010
- Location
- The Great White North
- Gender
Re: Programmers in the Playground
Yes, I know Perl. But I suggest to take your questions to a Perl site where you may get answers faster.
Some useful Perl links:
How do you keep a fool busy? Turn upside down for answer.
˙ɹǝʍsuɐ ɹoɟ uʍop ǝpısdn uɹnʇ ¿ʎsnq ןooɟ ɐ dǝǝʞ noʎ op ʍoɥ
-
2015-06-09, 06:16 PM (ISO 8601)
- Join Date
- Feb 2009
- Location
- A nice, sparkly place.
- Gender
Re: Programmers in the Playground
Don't worry, it should be very basic perl, so it shouldn't be difficult for experienced users. I just dislike unix coding and so its proved troublesome to remember all and to design the code properly. Basically, here are the assignment rules:
-It needs to display some "info" from a flat file,
-It needs to have multi-subroutines.
-It needs to have:
--loops,
--decision processes,
--arithmetic
--comparison
--output
That's all the constraints and rules it needs. The idea I want to have is make a NPC generator. Basically I'd have a few different monsters on a separate file for it to access, be it orc, gnome, troll, etc. Then the user can determine how many of that type of monster to generate, give it a few weapon choices and design a numbered stats attributed to each of the different monsters. Would you guys be able to help me out in the process of designing this and helping it to get it to work?
-
2015-06-09, 06:33 PM (ISO 8601)
- Join Date
- Dec 2010
- Location
- The Great White North
- Gender
Re: Programmers in the Playground
OK, start with that. What is the format of the file? Perhaps you want a CSV (Comma-Separated Values) or an INI file.
How do you keep a fool busy? Turn upside down for answer.
˙ɹǝʍsuɐ ɹoɟ uʍop ǝpısdn uɹnʇ ¿ʎsnq ןooɟ ɐ dǝǝʞ noʎ op ʍoɥ
-
2015-06-09, 07:26 PM (ISO 8601)
- Join Date
- Feb 2009
- Location
- A nice, sparkly place.
- Gender
Re: Programmers in the Playground
-
2015-06-09, 07:51 PM (ISO 8601)
- Join Date
- Dec 2010
- Location
- The Great White North
- Gender
Re: Programmers in the Playground
How do you keep a fool busy? Turn upside down for answer.
˙ɹǝʍsuɐ ɹoɟ uʍop ǝpısdn uɹnʇ ¿ʎsnq ןooɟ ɐ dǝǝʞ noʎ op ʍoɥ
-
2015-06-09, 08:29 PM (ISO 8601)
- Join Date
- Feb 2009
- Location
- A nice, sparkly place.
- Gender
Re: Programmers in the Playground
-
2015-06-10, 01:29 AM (ISO 8601)
- Join Date
- Feb 2012
- Location
- Germany
Re: Programmers in the Playground
From a data source perspective, yes. As long as your data is relatively nice and simple CSV is a fine choice to store your data. From your program you can then simply read the file line by line and split the line into an array an go from there.
I recommend to actually make multiple files, because storing different data in different files makes things much simpler.
If your data gets more complicated you probably want to use some other format, though they are harder to access/parse. For example XML is a quite useful format for more complicated stuff, but you basically need to include a library to do the parsing for you. Well, unless you want to write a parser
Problems with [table]?
All you want to know about [table]!The Order of the Stick
Kickstarter Reward Collection
Last updated: 2016/08/09, containing:
9 Crayon Drawings | 21 Stick its | 47 Signature Doodles
Custom Avatar made by the Giant.
Thanks!
-
2015-06-10, 02:29 AM (ISO 8601)
- Join Date
- Feb 2007
- Location
- Manchester, UK
- Gender
Re: Programmers in the Playground
I would be inclined to go straight for XML in this instance--it's pretty much designed for a data structure like this. e.g. you could have a bunch of entries like:
<RACE>
<NAME>ORC</NAME>
<LEVEL>1</LEVEL>
<HP>8</HP>
</RACE>
...and so on, adding additional information to each record as required.
-
2015-06-10, 03:36 AM (ISO 8601)
- Join Date
- Dec 2010
Re: Programmers in the Playground
Every complexity you add in the data storage format is going to add complexity both in the reading/writing capabilities in your main code, as well as in the tool choice you have available to you in order to edit your storage files. So you have to balance that complexity against the amount of data you have and how difficult it will be to work with and maintain that data using a less explicitly organized format.
E.g. if you have 10 data rows with 4 features each, and every row has every feature, XML is really overkill. But if you might eventually need 1000 rows, with some features only being associated with some rows, etc, etc...
Either way, my preference would be to choose formats that are convenient both to your code and to your favorite data entry software. So if your language has readily available libraries for reading in some particular format that you also happen to have software to edit easily, just go ahead and use that format. That's one big reason I might prefer something like CSV over XML - I can edit it in gnumeric and import it with one or two lines of code in most languages.
-
2015-06-10, 06:37 AM (ISO 8601)
- Join Date
- Dec 2010
- Location
- The Great White North
- Gender
-
2015-06-10, 06:51 AM (ISO 8601)
- Join Date
- Jan 2006
- Location
- UK
- Gender
Re: Programmers in the Playground
Given a week to do the whole program I would tend to stick to something simpler like a csv. Just be absolutely sure you don't need commas in the data itself. I tend to use tab-delimited, ; delimited or |-delimited for this reason, but it won't be an issue unless you let it be.
The other advice I will give at this stage is to keep the original spec. reasonably simple - don't start with all the stats, AC, HP, equipment. Make a basic program that does one part to completion (say racial choice & stat-generation), then once this is working and tested start adding more elements if you want. This makes it much easier to have something complete to hand in in your limited timeframe, even if it does not have all the functionality you originally planned.
If you plan the whole complex thing out, you may only get halfway through before the deadline, which I suspect is going to be worse for your marks than a more basic program that actually works.
-
2015-06-10, 07:06 AM (ISO 8601)
- Join Date
- Jun 2007
- Location
- Non Sequitoria
- Gender
Re: Programmers in the Playground
Another option, and not sure that I'd actually suggest it would be JSON. Has a lot of the same things going for it as XML but you say it with a lot less space. It's also not exclusively a JavaScript thing but the name has kind of stuck.
CSVs are probably your best bet for a simple project though.Last edited by Xuincherguixe; 2015-06-10 at 07:07 AM.
Spoiler
Rizban: You could be all, "Today's Destruction is brought to you by the color green.... I HATE GREEN!" then fly off mumbling to yourself "Seven... seven bats... mwa ha ha ha..."
Don't mind me. I'm just going to have some post traumatic flashbacks in the corner here and sob uncontrollably.
Millenium Earl by Shmee
-
2015-06-10, 09:22 AM (ISO 8601)
- Join Date
- Mar 2008
- Location
- NYC
- Gender
-
2015-06-10, 09:27 AM (ISO 8601)
- Join Date
- Jun 2007
- Location
- Non Sequitoria
- Gender
Re: Programmers in the Playground
Spoiler
Rizban: You could be all, "Today's Destruction is brought to you by the color green.... I HATE GREEN!" then fly off mumbling to yourself "Seven... seven bats... mwa ha ha ha..."
Don't mind me. I'm just going to have some post traumatic flashbacks in the corner here and sob uncontrollably.
Millenium Earl by Shmee
-
2015-06-10, 09:37 AM (ISO 8601)
- Join Date
- Dec 2010
- Location
- The Great White North
- Gender
Re: Programmers in the Playground
How do you keep a fool busy? Turn upside down for answer.
˙ɹǝʍsuɐ ɹoɟ uʍop ǝpısdn uɹnʇ ¿ʎsnq ןooɟ ɐ dǝǝʞ noʎ op ʍoɥ
-
2015-06-10, 10:00 AM (ISO 8601)
- Join Date
- Dec 2006
- Location
- Raleigh NC
- Gender
Re: Programmers in the Playground
Other people have already answered, but in brief:
1) Cleartext passwords are bad because they are easily stolen. Even in source code, someone scanning the source code instantly has access to that account.
2) Hard-coding passwords is also a terrible idea. If you change the password (as you should, on a regular basis), you also have to recompile the code and distribute the new program to everywhere as an update.
There are a number of solutions to this, some better and some worse. Storing the passwords in an encrypted format is best, if you can swing it. Storing the password in a digested or hashed format (as in Unix's /etc/shadow file) is better than nothing, but still not good if you can help it. The reason is that if someone gets access to a hashed password, they can crack it by brute force, trying multiple combinations against a common hashing algorithm until a hash of a guess matches the hash in the file.
For instance let's say I have the string
joe:abedc#44
So user 'joe' has a password which hashes to 'abedc#44'.
If I'm a hacker and i have access to this, I just move the file to my local computer and pull up a hashprogram against a dictionary or set of dates or what not.
guess 'birthday' : q4wrdfasg!!
guess 'baseball' : zxfgwrwer33
guess 'flittershy' : abedc#44
SOLVED. Joe's password is 'flittershy'.
You can't do this with proper encryption, because an encryption can't be solved with a generally-available algorithm. Instead, you need the algorithm plus the specific values used as keys -- inputs to the algorithm -- the private and public keys of the encryption.
So hashing isn't really going to protect you from a serious hacker, but it's better than just leaving the passwords out in clear.
When you put the password in cleartext AND hard-code it -- well, that's just plain lazy.
...
I suppose it would make sense if you were never, ever going to change the password -- if it was something done purely to bypass an unnecessary security filter -- and if you don't care at all about the stuff the password is supposed to protect. Even then, I prefer to store anything capable of changing in a parameter .xml file or a database. That way, if it needs changing, you don't need to rebuild the entire program!
Respectfully,
Brian P."Every lie we tell incurs a debt to the truth. Sooner or later, that debt is paid."
-Valery Legasov in Chernobyl
"As for the rest, I'd like to take a moment to compliment your dedication to rational discussion. You are a gentleperson and a scholar, and I salute you."
-- DaedalusMkV
-
2015-06-10, 10:22 AM (ISO 8601)
- Join Date
- Feb 2009
- Location
- A nice, sparkly place.
- Gender
Re: Programmers in the Playground
Okay. Some of the perl stuff went over my head (And when I said some, I mean most of it). What I understand is to make a separate file in the format shawn put and start coding by making sure the program can initially access the program and perform the loops and everything afterwards. Also, I am trying to make this as simple as possible. My teacher said he doesn't want anything complex, so just 2-4 creatures with the bare basic of stats and items to attach to them while also having an output of those stats and items once they are created is all I need. This program isn't going to be used in conjuncture with another program later on, this is the final project in my class. The reason I'm in a rush is the rest of the class has next week to finish the project. I, however, am leaving a week early so I need to have it done before then.
Last edited by Silverraptor; 2015-06-10 at 10:23 AM.
-
2015-06-10, 10:36 AM (ISO 8601)
- Join Date
- Feb 2007
- Location
- Manchester, UK
- Gender
Re: Programmers in the Playground
An XML file still fulfils the definition of a flat file in computer terms--it's a single file containing all the information for your database in a mostly human-readable and human-editable format. It's no different from JSON, INI, CSV, or any other text file data format in that regard.
-
2015-06-10, 10:58 AM (ISO 8601)
- Join Date
- Dec 2010
- Location
- The Great White North
- Gender
Re: Programmers in the Playground
How do you keep a fool busy? Turn upside down for answer.
˙ɹǝʍsuɐ ɹoɟ uʍop ǝpısdn uɹnʇ ¿ʎsnq ןooɟ ɐ dǝǝʞ noʎ op ʍoɥ
-
2015-06-10, 12:15 PM (ISO 8601)
- Join Date
- Aug 2010
Re: Programmers in the Playground
Yeah, CSV is probably the best choice in this situation.
If you really need a full text-based object serialization method, I'd always recommend JSON or YAML over XML *unless* you need others to automatically generate proxies based on an .xsd.
-
2015-06-11, 04:59 AM (ISO 8601)
- Join Date
- Jan 2006
- Location
- UK
- Gender
Re: Programmers in the Playground
THis sounds about right. You say you need:
--loops,
Reading through the file line by line shows this
--decision processes,
I assume the user will 'pick' a creature to output somehow (could be a command line parameter to make life a bit easier). This wouold take care of that
--arithmetic
Not sure what you plan here. You could do random stat generation (3d6 for ease) - that would cover loops and arithmetic
--comparison
Choosing a creature would handle this, otherwise random stat generation of 4d6 drop lowest would handle this. A bit trickier though, might be a bit more complex than you want depending on your confidence in your Perl knowledge
--output
Writing out to screen and or file handles this
Good luck, hope it goes well!
-
2015-06-11, 05:45 AM (ISO 8601)
- Join Date
- Dec 2014
- Location
- Tron Spacetime
Re: Programmers in the Playground
Hahaha, you funny guy you.
SpoilerT̴̡ͯ̀̐̑͊̇҉̥̰̺̥̯̰H͙̎̓͂ͭͅE̵̟̬̠̖̻͖ͬ̎͐̋͆͊̐̚ ̖͖̘͆ͤ̊̿͋̇͛͒ͮ͜͢R̩̪̪̥̝̯͔̰̃̓͛̒͊̇̓E̹̩ͮ̅́͐̄͗͂͠Gͪ̎͗̃ͨ̈́̂̔ ̈͏̡͇̺̟͔̩̕E̳̟͍̔̓̽̔͂X̳͍͎̊ͧ ̳̖̺͔͉̳̞ͬͯ͌͂̽ͤH̪̜͈̟̻̰̄͊͗̄ͨ̔͢U̟͔̪̟͙̙̠̼̜̅͊̾ͨ͆̍̓Ṅͯͪ͊̒ ̪͔͎̈̑G̗̖̞̜͔̓ͭ̊ͭͩ̇̎́̌E̢̤̺̘̜̜̰͚̓̓ͩ̑ͫR̴͙̭̺̬̲͑̾͒ͨ͜͝S̋̐ ̫̉̋ ̵̧̬̞̜͔̤ͫͧ̆ͤͅͅF̵̩̭̣̻͈̩̯ͥ̅͊̃̒ͨ͢ͅO̧̲̤̘̦̼̎̒̐̃͋͛̚R͒́ͨͧ̚ ̯̫̬͚͖͐ͅ ̼̩͇̫͆͒̌ͫ͂S̝̞͖ͫ̆ͪ̊̇̏ͭ͟Ỏ̷̼̥̿ͦ͒ͦ̃ͤ̀U̢̺̥̯͂̄͋ͣ̊̏L̈́͑ͣ͗͌ ̸̢͈̳͔̜̝̯̺͉̅̾̂͜S̙̱̥̬͒̅ͣ̽̽͝