So, how does one do web security in this instance?

[MutantJohn]

Let's say that I wanted to design an internet-based web app that allows the user to do a lot of awesome server-side stuff. It's basically, client request (facilitated through button presses or something) for server-side task. I want to make sure that only specific users can use this tool.

How do I go about this?

Do I really just create a login page and that's that? Make sure the password and username match up with a preexisting account? Like, I'm kind of thinking about Wells Fargo and it's pretty much just that.

Also, what's the standard level of security I should go for if I wanted to make this is a product. Like, how much time/effort should go into security?

[Yarin]

Make sure the password and username match up with a preexisting account? Like, I'm kind of thinking about Wells Fargo and it's pretty much just that.

Yep, pretty much that. If you're paranoid, you can harden it with things like
* Two factor authenticate
* Lockdown after too many failed attempts
* Lockdown if the client UAS isn't whitelisted
* Lockdown if the client IP range isn't whitelisted
* Require a binary key by file or plugin
And if you're super paranoid
* Authenticate after login with webcam, lockdown if it doesn't match facial and audio profile.

Like, how much time/effort should go into security?

As much time as is needed.

[Nominal Animal]

Also, obviously, use HTTPS.

I like to use cookie-based authentication for stuff like this. The cookies don't contain anything sensitive, they're just identifier tokens, intended to be very, very hard to fake/reuse. I like to tie the cookie to the user IP address, too. If you roam, you can always set up a VPN.

I prefer to have periodic randomization of the server-side salt ("secret") used to generate the hash (checksum) for the cookies, too, although single sign-on would requires lots of extra effort then.

[phantomotap]

Also, what's the standard level of security I should go for if I wanted to make this is a product. Like, how much time/effort should go into security?

O_o

I'm going to say... almost none.

You should be able to tick most everything suggested without really spending much time if you use an existing layer.

Seriously, you should grab an existing layer. Please, do not try to implement a security layer yourself. You can grab an implementation for virtually every software stack currently in use. If I correctly recall, you are a PHP and "MySQL" kind of guy. A few minutes with your favorite search engine will find you more than one implementation of a security layer living over a credentials table in a database having a hash function with tuneable cost offering a session identifier generator using time-based signing with address filtering and optional binding with existing two-factor providers.

Beyond a good implementation, you only need to repeat "less is better" as you figure out what information you require. Even if you do the implementation yourself, you simply can't leak information you never knew.

Soma

[Alpo]

Also, obviously, use HTTPS.

I like to use cookie-based authentication for stuff like this. The cookies don't contain anything sensitive, they're just identifier tokens, intended to be very, very hard to fake/reuse. I like to tie the cookie to the user IP address, too. If you roam, you can always set up a VPN.

I prefer to have periodic randomization of the server-side salt ("secret") used to generate the hash (checksum) for the cookies, too, although single sign-on would requires lots of extra effort then.

Are there any good ways to implement persistent authentication without cookies do you think? I suppose that's what most sites use.

Authenticate after login with webcam, lockdown if it doesn't match facial and audio profile.

Faces can be faked though, even little kids make faces. Best make it a full body and nude, for maximum protection (protection against meeting other people, since you can just see them naked anytime :P).

Do I really just create a login page and that's that? Make sure the password and username match up with a preexisting account? Like, I'm kind of thinking about Wells Fargo and it's pretty much just that.

The client side authentication can be done several different ways. Having a full stop authentication page is the most obvious, although I don't see it that often anymore. More often you just see slightly different HTML/script files being loaded depending on if you have the authentication or not. For instance Facebook used to let you browse around people's profiles, but you would need to be logged in to post or like something.

This second sort seems like the best option, people need to be able to use/look at your site before they decide to join it. It's a pain to plan out though, but I don't really feel qualified to give advice on what the best way to do it is.

[phantomotap]

Are there any good ways to implement persistent authentication without cookies do you think?

O_o

Yes. A cookie is just a way of adding somewhat persistent state to an otherwise stateless connection. You could always, for example, just POST the credentials every time you communicate with the server. (I would never simply POST credentials for the difficulty in getting everything safe. I'm just saying.) You can even find libraries available for at least Python and PHP languages that inject an identifier into relevant links automatically so that the client can sign a request in every communication with the server using some arranged token derived during the original signing process. Unfortunately, the security of placing a derived yet ignorant identifier in a cookie (The `httponly` and `secure` flags.) would be lost requiring similar security measures to be implemented in other layers.

Soma

[Alpo]

O_o

Yes. A cookie is just a way of adding somewhat persistent state to an otherwise stateless connection. You could always, for example, just POST the credentials every time you communicate with the server. (I would never simply POST credentials for the difficulty in getting everything safe. I'm just saying.) You can even find libraries available for at least Python and PHP languages that inject an identifier into relevant links automatically so that the client can sign a request in every communication with the server using some arranged token derived during the original signing process. Unfortunately, the security of placing a derived yet ignorant identifier in a cookie (The `httponly` and `secure` flags.) would be lost requiring similar security measures to be implemented in other layers.

Soma

I think I see, the strength would come from having less state information on the client that could be stolen at a later time, but requires a secure link to keep the token from being poached while you are making requests. That's pretty cool, I hadn't heard of that before, thanks!

[Mario F.]

awesome server-side stuff.

That there means "hacking the hell of it".

I wanted to make this is a product.

I'm not here to say anything useful -- I have only vague memories of web security and they are mostly about hashed passwords in databases. But here's a go at it: Don't. Don't make it a product. Very likely no one will use it. A direct line to server commands is the type of web app that most people won't trust even if it is developed by some of the best security firms in the business. The reason is there will always be dragons. And when they do, you'll have to wait for the developer to fix or patch them and you have to be on the lookout for the update. Meanwhile, everyone and their cat have been gladly hacking at your server. These type of applications are best developed in-house or by contract, so they can be used as you would a product, but in case problems arise you can provide a more immediate response.

[phantomotap]

I'm not here to say anything useful

^_^

Business as usual...

Soma

[MutantJohn]

If I correctly recall, you are a PHP and "MySQL" kind of guy.

This is why I love you, phantom.

These type of applications are best developed in-house or by contract, so they can be used as you would a product, but in case problems arise you can provide a more immediate response.

Interesting...

So, I was trying to come up with a type of DITA-based CMS. It's similar to what my mom's company is trying to do and when I was at work yesterday, I noticed people trying to update internal documentation but there's no unifying CMS, it's just Word files somewhere. It didn't seem to be going awesomely. In fact, this company doesn't even have a dedicated file upload program which gets super annoying because people just use like Filezilla or w/e. It's absurd. It's not that hard to code.

Sorry, I'm getting off-topic. Corporations frustrate me.

I'm trying to think of how to awesomely design a CMS using DITA as the main publishing engine. DITA is great because it takes XML-based content and can convert it to PDF, XHTML and I think there's a few more but those are the only important ones. DITA maps define the content structure so I wanted to build features like generating a map out of a SQL query, for example. This way it'd be easy to look at the entire contentbase, pull relevant info from it and either publish it or change it or something like that. Like, on-demand documentation that's customized for your particular use-case. It's also just a very easy way to have people maintain the content without having to ever learn what HTML is or something like that.

As of now, my mom's company can definitely not support a full cloud hosting system (though that would be my end goal) but I think if I design the app, I can just walk into a company and integrate it into their system. I be all like, "Y'all got a LAMP stack up in here 'cause I kind of need that." No, I guess I'll have to learn multiple databases and server-side scripts.

I asked myself is this a good idea and it turns out, some of these services already exist! It's interesting to see what the "competition" would look like XD

Seriously, I'm on a mission now. This is literally the only other thing besides meshing where I'm just like, "Oh, it's on now. It's on like Donkey Kong."

[phantomotap]

I think I see, the strength would come from having less state information on the client that could be stolen at a later time, but requires a secure link to keep the token from being poached while you are making requests. That's pretty cool, I hadn't heard of that before, thanks!

O_o

I really don't want to dive too deeply into the subject because we'll never really get much covered due to the complexity of the topic, but I did want to address the implications of the quoted comment.

Basically, you are mistaken. You wouldn't have a more secure layer thanks to "less state information on the client that could be stolen at a later time" with the alternative strategies I was referencing because the information shouldn't exists with any reasonable strategy when you correctly approach the security layers.

A secured cookie over HTTPS, a dumb POST strategy over unsecured HTTP for the initial connection, and everything in between can be designed such that the authorization token is unrelated to the actual credentials and expires from the perspective of both the client and the server. When you implement the security layer with the right techniques, the authorization token is only a nonce or similar and some sort of signature in the form of a hash of derived data arranged with filters and other connection specific information which can be generated or discovered independently by the client and the server. The client never knows the associated identity token. The server never knows the client's password. Despite the apparent lack of information, the server can identify the client without simply sending the proper credentials with every request thanks to the authorization token.

The authorization token is just a few bytes of data sent with every request in place of just sending actual credentials. The authorization token can be freshly generated with every request. The alternative strategy I referenced is just spreading the cost of generating and signing the authorization token between the client and the server so that the cost of avoiding sessions with cookies isn't completely paid by one party. You can use the same authorization token, which can't leak replayable information for later requests due to not having any such information, with or without cookies. (Of course, the authorization token should be made to expire to prevent other attacks in any event.) The cookie is just a way of adding persistence to the authorization token for the sake of user convenience.

Soma

[phantomotap]

This is why I love you, phantom.

O_o

You shouldn't tell lies.

We all know you love me for resplendent beard.

I'm trying to think of how to awesomely design a CMS using DITA as the main publishing engine.

I asked myself is this a good idea and it turns out, some of these services already exist!

o_O

You are really kind of sheltered, aren't you!?

[Edit]
I just find it kind of bizarre that your almost using the sales jargon of data transformation systems and content management systems to talk about your project.

I'm not trying to be insulting. Sorry.
[/Edit]

Soma

[Alpo]

A secured cookie over HTTPS, a dumb POST strategy over unsecured HTTP for the initial connection, and everything in between can be designed such that the authorization token is unrelated to the actual credentials and expires from the perspective of both the client and the server. When you implement the security layer with the right techniques, the authorization token is only a nonce or similar and some sort of signature in the form of a hash of derived data arranged with filters and other connection specific information which can be generated or discovered independently by the client and the server. The client never knows the associated identity token. The server never knows the client's password. Despite the apparent lack of information, the server can identify the client without simply sending the proper credentials with every request thanks to the authorization token.

That makes sense, you want a system that's secure even if the connection is compromised, which would be the case if I understand correctly. That's cool (even if confusing in the details).

[MutantJohn]

I just find it kind of bizarre that your almost using the sales jargon of data transformation systems and content management systems to talk about your project.

I'm not trying to be insulting. Sorry.

I know, isn't it amazing? I'm getting so much better at it! Ha, I love it!

[Nominal Animal]

Good summary, phantomotap.

Although I'd prefer completely random authentication cookies, I don't mind cookies with user name and user type in plaintext, as long as the cookie is securely signed. The user password should never have anything to do with the authentication cookie, or be any part of it, in any way.

What I am severely alarmed about, is the number of utterly idiotic solutions being pushed. For example, Apache 2.3/2.4: mod_session + mod_auth_form: "The mod_auth_form saves the user's login name and password within the session."

Yecch. When you treat your users as worthless livestock, anything goes, I guess.