Does anyone know if the server code is being exposed to the client?
There are 3 types of code. Server only , Client only and both.
Meteor releases authentication, accounts system, and new screencast
31–40 of 70 posts
Re: Meteor releases authentication, accounts system, and new screencast
#32I've used the Auth Branch for a few month now. You can see it in action at http://www.classfy.com (P.S: make sure you have the "www", or else you wont be able to access the page)
Re: Meteor releases authentication, accounts system, and new screencast
#33I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted,…
> Furthermore, nothing can protect you if your password is password.
I'm not sure why you threw this line in with the rest of your response. I don't see what point you're making.
Re: Meteor releases authentication, accounts system, and new screencast
#34I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted,…
I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle?
If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to have some form of security and still be able to load websockets and make CORS xmlhttprequests to other (non-secure) hosts - with the assumption that these hosts may also be man-in-the-middled). For now, the only alternative is to use something like a packaged app, if you want to make sure your code is actually your code, and still be able to load insecure resources.
Re: Meteor releases authentication, accounts system, and new screencast
#35I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted,…
> Furthermore, nothing can protect you if your password is password. I'm not sure why you threw this line in with the rest of your response. I don't see what point you're making.
What I meant by that is that a brute force offline attack will always succeed if your password is easily guessable regardless of what hashing or password verification protocols are used.
Re: Meteor releases authentication, accounts system, and new screencast
#36I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted,…
I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle? If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to…
It's not possible. What's possible is using a browser extension to verify some of the essential javascript and use that javascript to do further verification.
Re: Meteor releases authentication, accounts system, and new screencast
#37"Meteor 0.5.0, available today, allows you to write secure realtime client-server applications in pure JavaScript. It's the only system of its kind in the world." That's an outright lie. cf. http://opalang.org
SocketStream http://socketstream.com lacks the media blitz, but it provides authentication and integrates with pretty much anything in NPM (one of the stated goals of the author), and still provides all the benefits of a real-time framework like Meteor (for more than a year now)
Re: Meteor releases authentication, accounts system, and new screencast
#38Earlier quoted context omitted.
How in particular are they blocked by Mongo license? It's AGPL but it only applies to changes made to the database source code itself. It doesn't impose any requirements on your application if you are just talking to Mongo over the wire.
It is not unheard of for businesses in both the public and private sector to not allow AGPL code or use of applications released under this license. For example, I worked at a public library for years, and the policy was no AGPL, even if we had no intention of touching the source. Same for a local university. [Edit to add anecdote]
Nice to see libraries and local universities are thinking ahead for when they want to modify the source code of their database
Re: Meteor releases authentication, accounts system, and new screencast
#39"Meteor 0.5.0, available today, allows you to write secure realtime client-server applications in pure JavaScript. It's the only system of its kind in the world." That's an outright lie. cf. http://opalang.org
SocketStream http://socketstream.com lacks the media blitz, but it provides authentication and integrates with pretty much anything in NPM (one of the stated goals of the author), and still provides all the benefits of a real-time framework like Meteor (for more than a year now)
This is exactly why I love SocketStream. The extensibility of it is great. I can use one of the several thousand existing node modules/libraries and install them easily via NPM. In addition, development has been active and Owen (the lead dev) is extremely responsive to any issues on the GitHub repo.
He recently demo'd SS at LXJS 2012 - worth watching IMO: http://www.youtube.com/watch?v=LOS1lpWXphs
Re: Meteor releases authentication, accounts system, and new screencast
#40Looks like they finally took the suicide joke off their homepage.
it's still blank unless you execute the javascript
I have allowed most connections on NoScript and RequestPolicy in Firefox, but this website shows only the background image. How do they use many APIs or stupid JavaScript snipets to show something about SECURITY?