[QUOTE=NightmareX91;39967204]Why am I trying to learn brainfuck?[/QUOTE]
Because it's fun?
Tried learning brainfuck once but I got distracted...
I also raged
I prefer [url=http://en.wikipedia.org/wiki/Befunge]Befunge[/url].
Piet master race
[QUOTE=DoctorSalt;39963623]How do you guys back up your programming projects? Right now I:
Have VS 2012 back it up + Save it to Dropbox + git integration. Considering doing manual backup as well after I lost a project.[/QUOTE]
I have my different projects in private Bitbucket repos. Works great! Also it's awesome if you are developing on multiple computers, like if it's cross platform.
[QUOTE=Lexic;39966927]So? The n[I]once[/I] is only used once. The server then sends back a session token keyed to the user's IP address.
If you want to deal with the legitmate user changing IP then you can store the RSA+salted password in localstorage and do automatic javascript negotiation with the server if the session is invalid.[/QUOTE]
While that would protect against access from a third remote IP, this stores permanent authentication on the client, which is a bigger problem imo.
If there's a MITM that can listen to the connection, it can just as well spoof a connection from the legitimate user.
If you want protection against both, it would be necessary to use separate session and connection tokens. Maybe I'm misreading your post and this is what you mean by RSA+salted password.
[editline]19th March 2013[/editline]
[QUOTE=whoosy;39969397]I have my different projects in private Bitbucket repos. Works great! Also it's awesome if you are developing on multiple computers, like if it's cross platform.[/QUOTE]
The best part for me is how well it works with subrepos. I usually put all my projects in separate repos, then add them as subrepos to the solution repo.
If I want to use a dll in a separate program, I can just clone it into a subfolder there, then later apply the changes to the first solution by updating the subrepo and fixing anything that breaks.
It also helps a lot in keeping the change log organised.
[editline]bla[/editline]
The only downside is that synchronization is a bit slower. Hg pushes/pulls subrepos sequentially and there's always a short pause until Bitbucket answers.
[QUOTE=Lexic;39966927]So? The n[I]once[/I] is only used once. The server then sends back a session token keyed to the user's IP address.
If you want to deal with the legitmate user changing IP then you can store the RSA+salted password in localstorage and do automatic javascript negotiation with the server if the session is invalid.[/QUOTE]
So there's no way around me having to accept a plaintext password upon initial registration of a user? Because there's no way I'd be able to compare the response from the client to what the predicted digest would be unless I was storing passwords as plaintext as far as I can see, and I'm already using bcrypt to store them.
[editline]19th March 2013[/editline]
Maybe I'm just not understanding how to properly implement digest access authentication, or if I simply can't use it alongside bcrypt due to the method of storage for the password.
[editline]19th March 2013[/editline]
I reread the Wikipedia article on this, and I think maybe I'm getting it now; I suppose it would be impossible for me to use bcrypt along side digest access authentication, because I'm suppose to be storing HA1 such that:
[IMG]http://upload.wikimedia.org/math/d/6/f/d6f4d9252a0f57569e9fb1d35aa801a1.png[/IMG]
...so I can later return response to the client such that:
[IMG]http://upload.wikimedia.org/math/4/f/1/4f1e54d9cb5ef0797bf9c91e0355f280.png[/IMG]
Implying that I can't verify HA1 without a storage of HA1 as-is in, correct?
[editline]19th March 2013[/editline]
So this would mean I'm either storing passwords with bcrypt over HTTPS from a plaintext POST, or I'm using digest access authentication exclusively (presumably with HTTP, as noted as a basic solution to lack of SSL as noted in RFC 2069... from 1999... when SSL wasn't generally viable as a widespread cheap solution...).
[editline]19th March 2013[/editline]
Fuck me, I best just buy a cheap SSL, right? I was sort of trying to find a solution that could be used regardless of knowing the limitations of an unencrypted connection, but also provide conventional security with one. I guess I was asking for too much.
[QUOTE=dije;39967011]Shouldn't be coding before a national exam in physics I have in an hour, but I do it anyway[/QUOTE]
Fuck the police, comin' straight from the underground.
I think it's quite nice now:
[t]https://dl.dropbox.com/u/41041550/Coding/C%23/OGLFV/horizons.PNG[/t]
Just had to read through ~7KiB of machine code hex dumps to find a bug in my compiler... Here's the section where I found the problem:
[code]1660: 80 23 7d 00 16 68 16 68
1668: 80 23 7d 90 17 40 17 40
1670: 80 27 7d 00 16 78 16 78
1678: 80 27 7d d8 16 80 16 80
1680: 80 25 7d 00 16 88 16 88
1688: 80 25 7d ea 16 90 16 90
1690: 80 26 7d 00 16 98 16 98
1698: 80 26 7d 60 18 58 18 58
16a0: 80 27 7d 00 16 a8 16 a8
16a8: 80 27 7d f4 16 b0 16 b0
16b0: 80 25 7d 00 16 b8 16 b8
16b8: 80 25 7d ea 16 c0 16 c0
16c0: 80 26 7d 00 16 c8 16 c8
16c8: 80 26 7d 30 18 58 18 58
16d0: 80 27 7d 00 16 d8 16 d8
16d8: 80 27 7d ff 16 e0 16 e0
16e0: 80 25 7d 00 16 e8 16 e8
16e8: 80 25 7d e9 16 f0 16 f0
16f0: 80 26 7d 00 16 f8 16 f8
16f8: 80 26 7e 00 18 58 18 58 ## OOOH! Should be 0x7_d_00! This is because of writelabel not &0xff'ing the 256-x
1700: 80 28 7d 00 17 08 17 08
1708: 80 28 7d c0 17 10 17 10
1710: bf e6 7d 00 17 18 17 18
1718: bf e6 80 20 17 20 17 20
1720: bf e6 bf e6 17 28 17 28
1728: bf e7 7d 00 17 30 17 30
1730: bf e7 80 21 17 38 17 38
1738: bf e7 bf e7 bf e0 bf e0
1740: 80 a3 7d 00 17 48 17 48 # end of wakescreen
1748: 80 a3 80 28 17 50 17 50 # start of function write4bits
1750: 80 a4 7d 00 17 58 17 58
1758: 80 a4 7d f1 17 60 17 60[/code]
at 0x16f8, where the code's writing the return address to the link register for write8bits, it's reading from the wrong constant address. This is because of a bit twiddling error that only occurs when I'm writing a label location to memory and the last byte is a zero, so it's no wonder I didn't find it :v:
This causes the function to return to 0x17ff instead of 0x1700, so it skips part of the wakescreen function. That would be why my code wasn't waking the screen properly!
So yeah that was some fun debugging, glad I found it in the end.
Video of the gates, fully lit:
[media]http://www.youtube.com/watch?v=yDj4GV31FPg[/media]
[csharp][a, b, c] = [1, 2, 3];
printLine a;
printLine b;
printLine c;
[a, b] = [5, 6];
printLine a;
printLine b;
[a, b] = [b, a];
printLine a;
printLine b;[/csharp]
Outputs:
[code]1
2
3
5
6
6
5[/code]
Implemented in 10 lines of C#:
[csharp] [FunctionAttributes(Hype.Fixity.Infix_15, "=", 0)]
public Void Assign(List targets, List values)
{
if (targets.InnerList.Count != values.InnerList.Count) throw new ExpressionException("Lists in multiple assignments need to be of same length");
for (int i = 0; i < targets.InnerList.Count; ++i)
{
Assign(new Identifier(targets.InnerList[i].Var.OriginalName), values.InnerList[i]);
}
return Void.Instance;
}[/csharp]
[QUOTE=acpm;39969995]So there's no way around me having to accept a plaintext password upon initial registration of a user? Because there's no way I'd be able to compare the response from the client to what the predicted digest would be unless I was storing passwords as plaintext as far as I can see, and I'm already using bcrypt to store them.
[editline]19th March 2013[/editline]
Maybe I'm just not understanding how to properly implement digest access authentication, or if I simply can't use it alongside bcrypt due to the method of storage for the password.
[editline]19th March 2013[/editline]
I reread the Wikipedia article on this, and I think maybe I'm getting it now; I suppose it would be impossible for me to use bcrypt along side digest access authentication, because I'm suppose to be storing HA1 such that:
[IMG]http://upload.wikimedia.org/math/d/6/f/d6f4d9252a0f57569e9fb1d35aa801a1.png[/IMG]
...so I can later return response to the client such that:
[IMG]http://upload.wikimedia.org/math/4/f/1/4f1e54d9cb5ef0797bf9c91e0355f280.png[/IMG]
Implying that I can't verify HA1 without a storage of HA1 as-is in, correct?
[editline]19th March 2013[/editline]
So this would mean I'm either storing passwords with bcrypt over HTTPS from a plaintext POST, or I'm using digest access authentication exclusively (presumably with HTTP, as noted as a basic solution to lack of SSL as noted in RFC 2069... from 1999... when SSL wasn't generally viable as a widespread cheap solution...).
[editline]19th March 2013[/editline]
Fuck me, I best just buy a cheap SSL, right? I was sort of trying to find a solution that could be used regardless of knowing the limitations of an unencrypted connection, but also provide conventional security with one. I guess I was asking for too much.[/QUOTE]
There's no reason why you wouldn't be able to use digest authentication with a password hash, the client just hast to replicate that operation as Lexic mentioned. Digest authentication is basically just an implementation of one-sided untrusted authentication after all, so it works with any kind of shared secret.
You only need the signed SSL cert to authenticate the server to the user (because the user has prior knowledge about the validity of the cert). If the user imports an unsigned cert this creates prior knowledge for that user on that system for subsequent connections for free (with the weakness that the user must register on a secure connection).
If you want to secure the registration over an insecure connection, you can use Diffie-Hellman to create a shared secret for encrypting/decrypting the key. (You could also just send the encrypted hashed salted password instead and store that directly, there's no reason for the server to know the original if you only validate against a hash anyway.)
There are only two completely secure options for storing the data that require no prior knowledge, while making active MITM sufficiently difficult:
Public key cryptography, which invalidates an account if it was created with an active MITM if the MITM goes away and client-side encryption where the server doesn't store any clear-text data at all.
Both only work if the MITM can't use an SSL-Strip equivalent, so the client needs to have a secure UI.
[del]I suppose it would be possible to implement an interactive zero-knowledge-proof that doesn't depend on client integrity, but that would require more than one password.[/del] No, that doesn't work :v:
You can build a reasonably secure system if you don't protect against registration-MITM attacks by only transmitting temporary secrets on login, but other than that it's impossible without creating a new secure channel that connects domain name and TLS cert.
[QUOTE=alexbard;39972727][video=youtube;nBIo95Bmni8]http://www.youtube.com/watch?v=nBIo95Bmni8[/video][/QUOTE]
Any info on that lighting? it's fantastic.
[img]http://puu.sh/2kFFz[/img]
Metatables are fun.
I have been working on cleaning up some old code for a Name Generator.
I'm pretty proud of the little thing myself, so have some sample output:
[code]Lertyristif
Pyomik
Odyntian
Rohan
Thuoh
Clowi
Haetha
Boopookorge
Rodar
Reytortona
Karleren
Thanu
Zelath
Elvyndav
Nyandonsor
Kylaj
Jonysiento
Mancobang
Wher
Clete
Olevendi
Munodian
Wastah
Miziontyre
Hamongtony
Batiairosl
Tavashl
Ilormanb
Diahash
Yamungooker
Emanicelva
Vertentwe
Mosharston
Rony
Manal
Kanurie
Loriellyna
Faig
Carsonoen
Zary
Denestyso
Hyrelembra
Lidordone
Meros
Tiancoti
Jamoni
Taterretari
Stexanevona
Dulea
Issaed[/code]
There are some issues but I think it's generally decent (And most of the names you can at least attempt to pronounce).
A sample of the debugging and showing how the names are made.
[code]getting: fr, got: a. (fra)
fra
getting: ra, got: e. (rae)
frae
getting: ae, got: l. (ael)
frael
getting: el, got: t. (elt)
fraelt
getting: lt, got: o. (lto)
fraelto
getting: to, got: n. (ton)
fraelton[/code]
It is seeded from a big list of proper names and makes the new names from them.
I can't remember what this method is called so if someone could possibly remind me on that?
[QUOTE=Map in a box;39964707]Quantum Computers break a lot of crypto algorithms, including RSA iirc[/QUOTE]
Quantum computers need to come a long way before they can factor the kind of numbers needed.
Shor's algorithm has thus far been succesfully been used to factor large numbers like 25 on a quantum computer.
[QUOTE=acpm;39969995]So there's no way around me having to accept a plaintext password upon initial registration of a user? Because there's no way I'd be able to compare the response from the client to what the predicted digest would be unless I was storing passwords as plaintext as far as I can see, and I'm already using bcrypt to store them.[/QUOTE]
Well my idea (which given I am not a security consultant is not necessarily a good one) went something like this:
When a client signs up, the server sends them a personal unique salt (which gets stored in the db w/ the hash) they then sha their password with it and send you the result. This protects the user's actual password from a mitm, though it does nothing for your website. You just have to hope that they're on a secure network. (Or that you're using SSL!)
Then, after they validate their email etc, they have to sign in. The server once again sends the personal unique salt to the user, this time along with a nonce. They once again sha their password with the salt (storing the result in localstorage) and then sha it again with the nonce. They return the double sha'd salted nonced password to you, which you can then compare using the same process. Then you send them a lovely key'd session token that's only valid for a day and that IP. Every time the session expires, the client auto-negotiates with your server in the background and restarts it without any user interaction using the previously stored hash)
The only problems I can see with this is that the user needs JavaScript enabled and a relatively modern browser.
All that having been said - bcrypt + ssl is probably a better plan, but I wanted to share mine anyway. :v:
The MITM would have the salt which would make it easier to brute.
[QUOTE=hogofwar;39973371]I have been working on cleaning up some old code for a Name Generator.
I'm pretty proud of the little thing myself, so have some sample output:
[code]Lertyristif
Pyomik
Odyntian
Rohan
Thuoh
Clowi
Haetha
Boopookorge
Rodar
Reytortona
Karleren
Thanu
Zelath
Elvyndav
Nyandonsor
Kylaj
Jonysiento
Mancobang
Wher
Clete
Olevendi
Munodian
Wastah
Miziontyre
Hamongtony
Batiairosl
Tavashl
Ilormanb
Diahash
Yamungooker
Emanicelva
Vertentwe
Mosharston
Rony
Manal
Kanurie
Loriellyna
Faig
Carsonoen
Zary
Denestyso
Hyrelembra
Lidordone
Meros
Tiancoti
Jamoni
Taterretari
Stexanevona
Dulea
Issaed[/code]
There are some issues but I think it's generally decent (And most of the names you can at least attempt to pronounce).
A sample of the debugging and showing how the names are made.
[code]getting: fr, got: a. (fra)
fra
getting: ra, got: e. (rae)
frae
getting: ae, got: l. (ael)
frael
getting: el, got: t. (elt)
fraelt
getting: lt, got: o. (lto)
fraelto
getting: to, got: n. (ton)
fraelton[/code]
It is seeded from a big list of proper names and makes the new names from them.
I can't remember what this method is called so if someone could possibly remind me on that?[/QUOTE]
That's pretty awesome, the names are fairly easy to pronounce in most cases! Well done. You've inspired me to have a go at a similar sort of thing.
Symboliser now handles literals (to a certain extent)
If it reads in, say, 10, the symboliser converts that to 10 (subsymbol int)
This means that if you want to find the type of any literal symbol, you can simply peek at its subsymbols as you go along
Woo for compiling stuff. Which is still a long way off at this rate
[QUOTE=Map in a box;39973859]The MITM would have the salt which would make it easier to brute.[/QUOTE]
Easier to brute than what? Your only other options are a) physically delivering the salt to the client via courier b) hashing it without a salt or c) just sending it unhashed.
Short of a) this is the most inconvenient thing you could do for them since they'll have to start the brute from first principals rather than with a rainbow table.
[QUOTE=Map in a box;39973859]The MITM would have the salt which would make it easier to brute.[/QUOTE]
Salts are meant for making rainbow tables useless, not to prevent brute forcing.
hey garry some guys told me in fpp that if i criticized you i would be banned, i want to prove them wrong
your pants probably smell funny
[highlight](User was banned for this post ("my pants do not smell funny" - garry))[/highlight]
[QUOTE=Lexic;39973523]Well my idea (which given I am not a security consultant is not necessarily a good one) went something like this: When a client signs up, the server sends them a personal unique salt (which gets stored in the db w/ the hash) they then sha their password with it and send you the result. This protects the user's actual password from a mitm, though it does nothing for your website. You just have to hope that they're on a secure network. (Or that you're using SSL!) Then, after they validate their email etc, they have to sign in. The server once again sends the personal unique salt to the user, this time along with a nonce. They once again sha their password with the salt (storing the result in localstorage) and then sha it again with the nonce. They return the double sha'd salted nonced password to you, which you can then compare using the same process. Then you send them a lovely key'd session token that's only valid for a day and that IP. Every time the session expires, the client auto-negotiates with your server in the background and restarts it without any user interaction using the previously stored hash) The only problems I can see with this is that the user needs JavaScript enabled and a relatively modern browser. All that having been said - bcrypt + ssl is probably a better plan, but I wanted to share mine anyway. :v:[/QUOTE] The only thing I would change is replacing the salted hash in local storage with a persistent session token that the IP-bound tokens are negotiated with. That way an attacker actually has to grab the password when the user types it in to get the permanent hash and the service can give the user a list of active sessions with the option to close them manually. [editline]20th March 2013[/editline] I switched my file system experiment over to [URL="http://www.pismotechnic.com/pfm/doc/"]Pismo File Mount[/URL]. It's cross-platform (Linux, Win, Mac), has good documentation, is free for non-commercial use and uses a Unix-style data locking system which is perfect for my use case. I haven't found out how to create drive letters so far, it can replace any file with a mount point though. The best part is that the VC++ library project for the managed API is properly set up and actually builds out of the box without any requirements (besides having VS 2010 installed) :dance: [editline]edit[/editline] The explorer extension that comes with it can mount iso and zip files in-place. (Temporarily replaces the file with a folder.)
[editline]edit[/editline]
There go the line breaks :v:
[QUOTE=Archive;39974469]hey garry some guys told me in fpp that if i criticized you i would be banned, i want to prove them wrong
your pants probably smell funny[/QUOTE]
He only bans for criticism if you're a jackass about it
[QUOTE=Lexic;39973523]Well my idea (which given I am not a security consultant is not necessarily a good one) went something like this:
When a client signs up, the server sends them a personal unique salt (which gets stored in the db w/ the hash) they then sha their password with it and send you the result. This protects the user's actual password from a mitm, though it does nothing for your website. You just have to hope that they're on a secure network. (Or that you're using SSL!)
Then, after they validate their email etc, they have to sign in. The server once again sends the personal unique salt to the user, this time along with a nonce. They once again sha their password with the salt (storing the result in localstorage) and then sha it again with the nonce. They return the double sha'd salted nonced password to you, which you can then compare using the same process. Then you send them a lovely key'd session token that's only valid for a day and that IP. Every time the session expires, the client auto-negotiates with your server in the background and restarts it without any user interaction using the previously stored hash)
The only problems I can see with this is that the user needs JavaScript enabled and a relatively modern browser.
All that having been said - bcrypt + ssl is probably a better plan, but I wanted to share mine anyway. :v:[/QUOTE]
This is actually very similar to what I had already planned.
[editline]19th March 2013[/editline]
[QUOTE=Map in a box;39973859]The MITM would have the salt which would make it easier to brute.[/QUOTE]
[QUOTE=supersnail11;39974232]Salts are meant for making rainbow tables useless, not to prevent brute forcing.[/QUOTE]
A MITM would also have any nonce, which is why I invoked the argument earlier to begin with, it's essentially just as bad off as using a client salt (it would have to be the same every time). My concern wasn't regarding using a nonce/salt, it was just to mask the original password.
My current model is to:
1. Use some sort of client hash,
2. send that instead of the password (this approach would also be used for registration!),
3. and store it with a pass through bcrypt.
I was thinking about [URL="https://code.google.com/p/javascript-bcrypt/"]using bcrypt on the client,[/URL] and sending that. A second bcrypt pass on the back end would be for storage, and comparison could then be possible.
A session token would then be sent as a cookie back to the client which would be valid for a day or until the client logs out or logs in again from a different location. The session token would be used for back end method access.
[editline]19th March 2013[/editline]
I think that's probably pretty conventional (in a good way), but I dunno. I'm looking to approach this in the most generic, but secure way possible.
[editline]19th March 2013[/editline]
Obviously, the only remaining issue that stands is the fact that if a MITM stole the password hash, they'd basically be able to login as the victim and generate a session token until the victim changed their password and had their hash stolen again, and hijacking the session token obviously gives them temporary access as well, but if they get the initial login, then they can preferentially use that instead.
I haven't posted for a while, but if you remember my Astrostruct game I was working on-- I originally ditched the project, but my teacher needed a game STAT. So I buckled down for a week and repurposed it into a little light-based adventure game.
Check it out:
[vid]http://bit.ly/WUxjpN[/vid]
Ignore the random flickering of my file manager, gnome happens to be a massive jerk when it comes to recording desktop videos.
Wow, that's awesome man
[QUOTE=acpm;39977156]I was thinking about [URL="https://code.google.com/p/javascript-bcrypt/"]using bcrypt on the client,[/URL] and sending that. A second bcrypt pass on the back end would be for storage, and comparison could then be possible.[/QUOTE]
You want to try running that on MSIE's JScript engine? I don't. Besides, if you're trying to make a standard password system you can't really depend on the client having an acceptably modern and standards compliant browser. People browse the net on a startlingly large variety of things including TVs and actual phone phones (opera mini worst browser.)
[QUOTE=Tamschi;39974984]The only thing I would change is replacing the salted hash in local storage with a persistent session token that the IP-bound tokens are negotiated with.
That way an attacker actually has to grab the password when the user types it in to get the permanent hash and the service can give the user a list of active sessions with the option to close them manually.[/QUOTE]
I like it, though it does add an entire extra layer of complexity onto the system. For fun, why don't we make the persistent session tokens keyed to your user agent string? :v:
Sorry, you need to Log In to post a reply to this thread.
