Account Creation Help

Questions
1

I’m working on a local account system. I though localData would be the way to go, but it appears not.

    local user = inputTab[1].val
    local pword = inputTab[2].val
    local data = readLocalData(user, pword))
    if readLocalData(user, pword) == nil then
        inform = "Log in failed: Account doesn't exist or password is incorrect."
        failed = true
        print("failed")
    end

Here’s my issue. When they press the login button It logs them in anyway. I think this is because if in readLocalData(user, password) doesn’t exist, it creates it. I’m a beginner coder so I’m not sure what to do at this point.

Any help would be appreciated.

2

@FearMe2142 - try this

local data = readLocalData(user)
if data~=pword then --failed

EDIT - the reason it wasn’t working was that if you provide a second parameter to readLocalData, it is used as the default value! Have a look at the built in reference (or link at top) for more.

3

@Ignatz

I looked at the reference, but didn’t fully understand it, however this makes more since thanks to your example. Thank you!

4

@FearMe2142 readLocalData() isn’t going to create anything. It will only read what you give it. If it logs them in and (user,pwrd) isn’t correct, then your code isn’t correct.

5

@dave1707

Doing what ignatz said worked and solved the issue.

Is there a way to store multiple data inside a key for example;

saveLocalData(user, password)
saveLocalData(user, email)

6

Maybe something like saveLocalData(“keyvalue”,“user,password”)

7

You could do something like this. I’m not sure what you would use for the key, but here’s an example anyways.

function setup()
    saveLocalData("key","john01,pword123")
    data=readLocalData("key")
    user,password=string.match(data,"(%g+),(%g+)")
    print(user,password)
end
8

This would be a very insecure way of storing passwords, but I’m guessing it doesn’t really matter too much, in this case.

9

@Ignatz
For now anyway, it’s just going to be local. Where exactly should I read up at about creating secure accounts?

@dave1707
Thanks I went with
saveLocalData(user…“Email”, email)
saveLocalData(user…“Password”, password)

10

@FearMe2142 - first, you should never store passwords, but “salted” hashes of passwords (google this), and it should not be possible to either replace them, or edit the code. Storing plain text passwords breaks all those guidelines.

I think I’m right in saying that Codea’s code is also stored in plain text, so it could be altered (eg to skip the login).

There is no way to password secure a Codea project unless both the code and password file can be securely protected.

However, I think the amount of effort you go to should depend on how much effort you expect users to take to break your passwords, and how bad it would be if they did.

11

@Ignatz

Thank you a lot for all the help, I’m going to look into this more!

12

https://github.com/Utsira/WorkingCopyCodeaClient/blob/master/tabs/Request.lua

@FearMe2142 @Ignatz @dave1707 , try the link. Its yojimbos code. It is a way to store data on an WebDAV server

13

Actually, if you’re looking at that repo, the sha1 library might be more useful.

https://github.com/Utsira/WorkingCopyCodeaClient/blob/master/tabs/Sha1.lua

I have no idea whether sha1 keys are considered acceptable for storing passwords. I just use them for file integrity (rather than security), to verify read/write operations.

14

But if you’re heading for the App Store via Xcode, the code would be a fairly secure binary, no? (I know nothing about encryption)

15

If people don’t have access to your code to see what kind of encrypting you’re doing, then even a simple routine could be enough.

16

I’m sure Sha1 is fine for Codea, there are much bigger security issues than that, such as securing the password file and especially the code. I wouldn’t use Codea for anything where security was really critical.

17

I remember reading something on the forum about the code being readable after publication on the store, but I’ve never gone that far, so I can’t be sure. Certainly, anything stored with saveLocalData is going to be readable and editable by anyone who can hack the iOS file system.

I’ve read a lot about encryption, and the overriding message I get is that it is incredibly hard to get right. Codea isn’t designed for security, so it would be even harder to hack proof it. (That’s not a criticism, of course!).

18

I don’t see a problem with saveLocalData. Even if someone can read and edit the file, simple encryption will work unless a professional hacker gets the file. I don’t think a professional hacker is going to waste their time on something small. If someone edits the file, that just messes it up and it won’t work anyways.

19

That’s pretty much what I said above. If you don’t need high security, Codea is fine. If you need high security, don’t use Codea.

20

@dave1707
@Ignatz

I didn’t really need High Security. I’m building my own note taking app. Just needed a way for students to not pick up and delete someone’s notes mischievously. It’s only protecting notes you right down.

Thank you so much!!

Codea has really allowed me to innovate and I appreciate all the help from the community.

I hope to have the app up by spring. Possibly January 17th. I’m busting my arse over Christmas break.

The only thing I need encryption based is the ITunes purchase which would be $10.00 a year for the account, but Apple has a guide for that I believe.