Jump to content




XLogin - The fast login program!


21 replies to this topic

#1 Spexiono

  • Members
  • 14 posts

Posted 23 February 2014 - 08:11 PM

XLoginV1.8

The login program designed for usability


pastebin get fnrUKmgX startup

GitHub

Hey! This login program is one of my first completed programs.
I've been tweaking and playing with XLogin since i first tried out ComputerCraft and i think it's about time i released it on the forums.

Note:
The default username is: "name"
The default password is: "1234"
I highly recommend you change these (For obvious reasons)
However there is no security or encryption for storing the login details, use this program at your own risk!

Features
  • One version for standard and advanced computers
  • Minimal support for turtles (So far)
  • No delays or sleep functions
  • Modem detector
Spoiler

Credits and thank yous:
  • Thanks to BigSHinyToys and his thread for the Modem detector.
  • Thanks to Bomb Bloke for making me the indentprint() function.
  • And thanks to everybody who has provided help and tutorials on the forum and the wiki, I'd never have gotten into ComputerCraft otherwise.

Questions, comments and suggestions are all welcome! :)



#2 Alice

  • Members
  • 429 posts
  • LocationBehind you.

Posted 23 February 2014 - 09:26 PM

So what's the use of this exactly?
I mean, it looks cool and anything but it's a computer login system. I don't see the use of it.

#3 Spexiono

  • Members
  • 14 posts

Posted 23 February 2014 - 09:42 PM

View PostDeath, on 23 February 2014 - 09:26 PM, said:

So what's the use of this exactly?
I mean, it looks cool and anything but it's a computer login system. I don't see the use of it.

You're right, it's mainly just a nice looking login program :)
I've basically just expanded on the countless login programs that you find on the web, it shows you the computer's ID, label and if it has a modem on it before and after you login, I may cut it down to a more minimal program in the future and remove a bunch of the extra features.
I just wanted a login program that didn't make you wait through: print("Loading...") sleep(1) etc.

#4 Alice

  • Members
  • 429 posts
  • LocationBehind you.

Posted 23 February 2014 - 10:15 PM

One thing I thought would be cool is to have a file, .info, and that will hold the information. Most file browsers on the forums block programs/folders starting with '.', and will keep the file secret from 'ls' or 'dir'

#5 Spexiono

  • Members
  • 14 posts

Posted 23 February 2014 - 10:45 PM

View PostDeath, on 23 February 2014 - 10:15 PM, said:

One thing I thought would be cool is to have a file, .info, and that will hold the information. Most file browsers on the forums block programs/folders starting with '.', and will keep the file secret from 'ls' or 'dir'
yeah, I've been looking into that a bit, do you know where a good example or tutorial is for ComputerCraft file-system?
Once i've got that working i can get it to ask you to enter your own username+password if the file doesn't exist rather than relying on default passwords

#6 Alice

  • Members
  • 429 posts
  • LocationBehind you.

Posted 24 February 2014 - 12:48 AM

Not really a fs tutorial, I use the wiki/IRC for all needed information c:
I use dofile('.password') where .password is:
login = 'herp'
pass = 'derp'
c:

#7 Kingdaro

    The Doctor

  • Members
  • 1,636 posts
  • Location'MURICA

Posted 24 February 2014 - 03:47 AM

View PostDeath, on 24 February 2014 - 12:48 AM, said:

Not really a fs tutorial, I use the wiki/IRC for all needed information c:
I use dofile('.password') where .password is:
login = 'herp'
pass = 'derp'
c:
That's kind of unsafe. By doing that, the variables "login" and "pass" are both thrown into the global namespace for any program to access just by doing "print(login, pass)".

A better practice would be to read the file and store the values directly, line by line for example.

Password file:
herp
derp

Program:
local file = fs.open('.password', 'r')
local login = file.readLine()
local pass = file.readLine()
file.close()


#8 TheOddByte

    Lazy Coder

  • Members
  • 1,607 posts
  • LocationSweden

Posted 24 February 2014 - 05:55 AM

View PostKingdaro, on 24 February 2014 - 03:47 AM, said:

View PostDeath, on 24 February 2014 - 12:48 AM, said:

Not really a fs tutorial, I use the wiki/IRC for all needed information c:
I use dofile('.password') where .password is:
login = 'herp'
pass = 'derp'
c:
That's kind of unsafe. By doing that, the variables "login" and "pass" are both thrown into the global namespace for any program to access just by doing "print(login, pass)".

A better practice would be to read the file and store the values directly, line by line for example.

Password file:
herp
derp

Program:
local file = fs.open('.password', 'r')
local login = file.readLine()
local pass = file.readLine()
file.close()
Well that is very insecure if they don't hash the password before storing it into a file, It would also be good to override some fs functions to completly hide the password file and make it as secure as possible, But still make sure you can access the file.
Tips: If you would override a function it would be this
fs.list


#9 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 24 February 2014 - 06:06 AM

View PostHellkid98, on 24 February 2014 - 05:55 AM, said:

Tips: If you would override a function it would be this
fs.list
honestly I'd override io.open and fs.open. who cares if they can see it in the list, if they know the file they're looking for they can just open it.

#10 Kingdaro

    The Doctor

  • Members
  • 1,636 posts
  • Location'MURICA

Posted 24 February 2014 - 06:12 AM

View PostHellkid98, on 24 February 2014 - 05:55 AM, said:

Well that is very insecure if they don't hash the password before storing it into a file, It would also be good to override some fs functions to completly hide the password file and make it as secure as possible, But still make sure you can access the file.
Tips: If you would override a function it would be this
fs.list
This solution is outside the scope of the OP's problem.

#11 willwac

  • Members
  • 182 posts

Posted 24 February 2014 - 06:57 PM

Also, I just had a good idea for encryption.
Find a MD5 Web API, and find a way to securely pass the password to that web API.

#12 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 24 February 2014 - 07:18 PM

View Postwillwac (NewCoolPC), on 24 February 2014 - 06:57 PM, said:

Also, I just had a good idea for encryption.
Find a MD5 Web API, and find a way to securely pass the password to that web API.
I really hope you're being sarcastic there!

#13 crazyadam0

  • Members
  • 44 posts
  • LocationWashing a ton state USA, North America, Earth, The Universe, The Multiverse (If that exists)

Posted 24 February 2014 - 07:54 PM

View Posttheoriginalbit, on 24 February 2014 - 07:18 PM, said:

View Postwillwac (NewCoolPC), on 24 February 2014 - 06:57 PM, said:

Also, I just had a good idea for encryption.
Find a MD5 Web API, and find a way to securely pass the password to that web API.
I really hope you're being sarcastic there!

Tru Dat!
The best way to encrypt (I believe) is to use GravityScore's SHA256 lua implementation. Then generate a random string to be the salt, append that to your password and then save the salt and the hashed password.
Also, MD5 isn't the greatest crptographic hash function...

#14 Alice

  • Members
  • 429 posts
  • LocationBehind you.

Posted 24 February 2014 - 09:01 PM

heh now that I think of it I remember designing a basic server once to use as a login server for my computer on PixelToast's server. I never finished it, however. Now that I have the idea in my head and a (laggy) server to run it on, I might go back to making it.

#15 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 24 February 2014 - 09:04 PM

View PostEnderbane, on 24 February 2014 - 07:54 PM, said:

Tru Dat!
The best way to encrypt (I believe) is to use GravityScore's SHA256 lua implementation. Then generate a random string to be the salt, append that to your password and then save the salt and the hashed password.
Also, MD5 isn't the greatest crptographic hash function...
Okay some corrections are needed here...

Firstly some terminology correction... Encryption != Hashing
Encryption is the obstruction of data using a key that when the key is applied again the data is back to how it originally was. An encrypted string can be variable in size depending on the data even when the same encryption method is used.
Hashing is the process in which a string is transformed into a different unique (ish, depends on the algorithm) string, unlike encryption this process cannot be reversed. A hashed string will always be the same length, no matter the length of the supplied string, for example if we were to hash "a" using SHA256 it will be a 64 character long string, and if we hash "hello, world" it will also be a 64 character long string.

Okay so now that is out of the way, time for the second correction, your use of salting is wrong. Lets assume we have the following 3 passwords and their respective hash values (not real hash output, I had no desire to type 64 characters to replicate a SHA256 :P )

password input: bob1990	  —> hash output: AD756GDM8
password input: password123  —> hash output: 835KDBGL0
password input: qwerty	   —> hash output: SDF89375N
password input: password123  —> hash output: 835KDBGL0

notice how obviously both the passwords "password123" come out the same, now lets assume we have the following salt "er*&34jksdf0". if we apply that to the above passwords in a manner you suggest, this is our outcome

AD756GDM8er*&34jksdf0
835KDBGL0er*&34jksdf0
SDF89375Ner*&34jksdf0
835KDBGL0er*&34jksdf0

notice how that changed literally nothing? ... okay well one reason we use a salt is to make sure that dictionary attacks will not work on the passwords, in the case of the above passwords a dictionary attack would actually notice the salt added onto the end of the strings — since all the strings have the same set of characters — and it would remove that from the string, meaning that we're left with just the original pre-salt strings, this means that dictionary comparisons would be no more difficult. So how do we improve this? simple, we add the salt to the password before we hash! by doing that we would then have the output like so (again not real hash values)

password input: bob1990er*&34jksdf0	  -> hash output: K4S67FKJ3
password input: password123er*&34jksdf0  —> hash output: SDJH3891J
password input: qwertyer*&34jksdf0	   —> hash output: 6KJH2HJ6F
password input: password123er*&34jksdf0  —> hash output: SDJH3891J

so the advantage here is that when it is performing the dictionary comparison of lets say 'password123' which had the result of "835KDBGL0" well now it is actually 'password123er*&34jksdf0' with the result of "SDJH3891J" meaning that the passwords do not match. Now you might say "how do we compare these passwords to the input password, simple just hash the input with the salt and compare the results, if they entered 'password123' with the salt added its output will become "SDJH3891J"

now you might notice an additional problem here, and that is that both of the 'password123' hash values are the same, even after the salt. well this can be a problem 'cause it means even with a salt if they crack one password they can crack all the other ones with the same hash result. commonly this is mitigated by making each password have a unique salt as well, meaning that even passwords that are the same will have different outputs, take this example

password input: "password123" —> salt: "er*&34jksdf0" —> password + salt: "password123er*&34jksdf0" —> hash output: "SDJH3891J"
password input: "password123" —> salt: "23fh*(#HJa42" —> password + salt: "password12323fh*(#HJa42" —> hash output: "AD756GDM8"

notice now how even though they are the same passwords, they're different hashes. now you may have the question "but how do we store those salts so we can use them again for later" and well the simple answer there is, however you want, as long as you store the salt somewhere and know which password it relates to you're fine. the reason for this is the common attacks on hashed passwords is the use of rainbow tables, which is just a bunch of pre-hashed passwords, why? well the process of hashing can take a long time (especially with some algorithms, the longer the better really), so even if you hand them your salt on a silver platter the likelihood of them being able to run through all dictionary values and hash them with your salt to find the match is low — this is assuming that the password is a strong password, which is why companies tell you to do it that way, so there's even less of a chance of them matching a dictionary word — no one would really do this.

however all of this being said, a simple hash in ComputerCraft is more than enough, especially when someone can just break your computer and/or door with a pickaxe.

#16 Spexiono

  • Members
  • 14 posts

Posted 25 February 2014 - 12:23 AM

Well, including password encryption may be out of my depth a little.
I'm looking at using Death's dofile('.password') but i made a little function that replaces the global values with nil whenever the program exits. does this solve the security issues? i assume it's still not quite optimal though.

#17 crazyadam0

  • Members
  • 44 posts
  • LocationWashing a ton state USA, North America, Earth, The Universe, The Multiverse (If that exists)

Posted 25 February 2014 - 12:45 AM

I apologize for my misuse of the terms "Encrypting" and "Hashing", I do understand the difference and applications of each, though it is easy to get confused for a semi-noobish programmer as my self. I do believe however that you misinterpreted how I used salts, or I just wasn't clear enough (most likely the later knowing your background). I did not store the hashed password with an appended salt. I generated a random salt and hashed the password and salt together, storing the salt (individual to each user) alongside the password-salt combo hash (sounds like some terribly unhealthy breakfast meal from McDonald's). In fact, the code I use to store passwords in my log in system is:

fs.makeDir("/.winMC/.user/"..usn.."/.system");
local file = fs.open("/.winMC/.user/"..usn.."/.system/loginInfo","w");
local salt = randomString(64) --Generate a random salt
file.writeLine(salt);
file.writeLine(usn);
os.loadAPI("/.winMC/.OS/APIs/sha");
file.writeLine(sha.sha256(pwd .. salt));--Write hashed password and salt to file
os.unloadAPI("/.winMC/.OS/APIs/sha");
file.writeLine(hnt);
file.close();
local confirmFile = fs.open("/.winMC/.OS/hasuser","w");
confirmFile.close();

Edited by Enderbane, 25 February 2014 - 12:50 AM.


#18 Alice

  • Members
  • 429 posts
  • LocationBehind you.

Posted 25 February 2014 - 02:00 AM

View PostEnderbane, on 25 February 2014 - 12:45 AM, said:

the salt (individual to each user)
Salts are meant to be static, are they not?

#19 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 25 February 2014 - 02:50 AM

View PostDeath, on 25 February 2014 - 02:00 AM, said:

View PostEnderbane, on 25 February 2014 - 12:45 AM, said:

the salt (individual to each user)
Salts are meant to be static, are they not?
I've gone ahead and edited my reply down shorter containing only the relevant information for your question...

View Posttheoriginalbit, on 24 February 2014 - 09:04 PM, said:

Lets assume we have the following 3 passwords and their respective hash values (not real hash output, I had no desire to type 64 characters to replicate a SHA256 :P )

password input: bob1990	  —> hash output: AD756GDM8
password input: password123  —> hash output: 835KDBGL0
password input: qwerty	   —> hash output: SDF89375N
password input: password123  —> hash output: 835KDBGL0

notice how obviously both the passwords "password123" come out the same. So how do we improve this? simple, we add the salt to the password before we hash! by doing that we would then have the output like so (again not real hash values)

password input: bob1990er*&34jksdf0      —> hash output: K4S67FKJ3
password input: password123er*&34jksdf0  —> hash output: SDJH3891J
password input: qwertyer*&34jksdf0	   —> hash output: 6KJH2HJ6F
password input: password123er*&34jksdf0  —> hash output: SDJH3891J

now you might notice an additional problem here, and that is that both of the 'password123' hash values are the same, even after the salt. well this can be a problem 'cause it means even with a salt if they crack one password they can crack all the other ones with the same hash result. commonly this is mitigated by making each password have a unique salt as well, meaning that even passwords that are the same will have different outputs, take this example

password input: "password123" —> salt: "er*&34jksdf0" —> password + salt: "password123er*&34jksdf0" —> hash output: "SDJH3891J"
password input: "password123" —> salt: "23fh*(#HJa42" —> password + salt: "password12323fh*(#HJa42" —> hash output: "AD756GDM8"

notice now how even though they are the same passwords, they're different hashes. now you may have the question "but how do we store those salts so we can use them again for later" and well the simple answer there is, however you want, as long as you store the salt somewhere and know which password it relates to you're fine. the reason for this is the common attacks on hashed passwords is the use of rainbow tables, which is just a bunch of pre-hashed passwords, why? well the process of hashing can take a long time (especially with some algorithms, the longer the better really), so even if you hand them your salt on a silver platter the likelihood of them being able to run through all dictionary values and hash them with your salt to find the match is low — this is assuming that the password is a strong password, which is why companies tell you to do it that way, so there's even less of a chance of them matching a dictionary word — no one would really do this.

however all of this being said, a simple hash in ComputerCraft is more than enough, especially when someone can just break your computer and/or door with a pickaxe.


#20 TechMasterGeneral

  • Members
  • 149 posts
  • LocationUnited States

Posted 25 February 2014 - 08:42 AM

Pretty nice dude!





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users