I don't know the foursquare API details but, in general, you should never send any authentication key on an unsecure channel. When accessing a resource from a web application you normally authenticate someway first and then you call its services directly relaying, normally, on the authentication cookie established earlier. When you access it through an app, mobile or desktop, and you can have a secure store for your secret, you can have an initial login/password authentication for exchanging the secret some way, store it, and then use it for hashing your requests. This way your secret will never be transmitted again but remember to include at least a timestamp in your hashing procedure in order to make your request expire.
Anyway, security is a very difficult problem and the attack surface is huge. Don't try to reinvent the wheel on this topic and try to use what is already implemented and the best practices of the technology stack you decide to build your application with. Oh, spend some time on https://www.*owasp*.org/ , it will not be that funny, probably, but it definitely worths the time. On Tue, Apr 1, 2014 at 10:15 AM, Calvin Crane <[email protected]> wrote: > Thanks so I feel I may be right and this means for any non http request to > an api server side like foursquare will reveal the secret key unless we do > the hashing ourselves. And for me that is a key concept as it therefore is > the same as doing it client side. Both are insecure is my point. > > Calvin > > On 1 Apr 2014, at 08:58, Alessandro Ghidini <[email protected]> > wrote: > > Calvin, you're talking about a channel security problem, not a client side > tecnology issue: whenever you're handling critical data you need to secure > and encrypt your channel at least with SSL (talking about the HTTP layer). > What you may consider critical belongs to your specific domain and business > rules but, surely, it includes the authentication phase with login/password > or with an api secret. > > Akshit, you're right, Angular is not secure and a skilled user will be > able to read your secret business rules, if you decide to embed them in > your client side sources, simply because your javascript files are a F12 > button away to be visible to the web application users. This is a > javascript "limitation" though and it influences every client side > framework as it does with angular. This is the reason why they say that > "you don't have to trust the user": you should use the client side code to > improve the user experience, like performing basic client data validation > avoiding useless round trips to the server, but the "real" business rules > have to be present on the server where you'll have to execute again the > validation you've just done on the client along with the authentication, > authorization and any other verification checks needed by your use cases. > > > > On Mon, Mar 31, 2014 at 10:54 AM, calvin crane <[email protected]>wrote: > >> I still am not sure that server side is fully secure but I do know its a >> common belief. >> Server side with correct sever admin helps secure the source ok and that >> can include for example a private app key. >> Server side requests data via http for me sends out API secret and token >> for example using foursquare app - this is no different in my mind to >> sending via the client. This is all unencrypted info that is available just >> because it runs on the server there is no magic backchannel ? >> I realise I don't help the OP here but am kind of asking for your guys >> input to help my own thinking. >> >> >> On Sunday, 30 March 2014 15:56:10 UTC+1, José Borba wrote: >> >>> First point: web is insecure; >>> Second point: the only way to keep your business logic secure is to keep >>> it in the SERVER side. >>> Third point (optional): use Angular for presentation only. Is what I do. >>> >>> Best regards, >>> >>> >>> 2014-03-30 11:40 GMT-03:00 Jeremy Likness <[email protected]>: >>> >>>> Angular is no different than any other browser-based technology. It is >>>> completely your choice to decide much logic runs at the client vs. the >>>> server and what trade-offs you are willing to make. >>>> >>>> What "business logic" is it you think will be hacked? Do you have a >>>> tangible example? For example, if your company has some special algorithm >>>> for determining how many widgets are going to be sold over the next two >>>> weeks, there is nothing in Angular to prevent you from hosting that >>>> algorithm on your server and just exposing the result as a web service end >>>> point. Angular's interceptors give you control over headers for >>>> authentication and to avoid cross-site forgery, etc. so I'm not sure I buy >>>> the argument that it is any less secure than the web in general, and if >>>> anything I'd say it supports making your apps more secure. >>>> >>>> Jeremy >>>> >>>> >>>> On Saturday, March 29, 2014 5:36:32 PM UTC-4, akshit mahajan wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am very new to angular JS, I read a few posts online that angular JS >>>>> is not a good choice security-vise. >>>>> >>>>> Since all the business logic that is written is present at the client >>>>> end(Browser), any hacker can attempt to hack the business logic easily! >>>>> >>>>> What are the expert's comments/suggestions in this scenario? >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "AngularJS" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> >>>> Visit this group at http://groups.google.com/group/angular. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> José Ricardo Borba >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "AngularJS" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Alessandro Ghidini > > -- > You received this message because you are subscribed to a topic in the > Google Groups "AngularJS" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/angular/iATsJIDlIGU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- Alessandro Ghidini -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
