Jump to content
  • Advertisement

Neil Cross

Member
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

5 Neutral

About Neil Cross

  • Rank
    Newbie

Personal Information

  • Role
    Programmer
  • Interests
    Art
    DevOps
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. How about rather than (or in addition to) using the player's orientation, use the player's current velocity to infer the desired destination. You could identify the desired target by determining the angle between the velocity vector and the target vector with respect to the player's position for each target and using the target with the smallest angle. In your example below the blue angle is the smallest and would be used as the default target. In your second example of falling off the ledge at point A, a similar calculation could be performed. I've included a diagram for discussion below: Based on this calculation, point B would still be preferred (which could be considered "correct"). However, if catching the ledge behind them is the desired action, using the velocity alone wouldn't be considered sufficient. You could be better served using a weighted combination of the velocity (v) and orientation (d) of the player to use as the heading vector as below: With this change in effect, a player facing left would still use grappling point B, but a player who has turned to face right will use point A. Just made this up, not implemented it nor analysed a similar existing mechanic before. How does this sound?
  2. Sony had plaintext passwords. Yahoo had unsalted passwords. All the well-known ones had either plaintext passwords, or significant personal data (addresses or social security numbers or credit cards). To put it another way, in the event of a data breach, which would prefer to be disclosed: all your user's usernames and password hashes, or all your user's email addresses and phone numbers?
  3. That's understandable, it's good you have a strong understanding of the importance of security. But do keep in mind you will only store a hash of the password, combined with a random salt per user, so the user's original password is unable to be retrieved (assuming a decent hash algorithm is leveraged) even in the event of a data breach.
  4. Neil Cross

    Opensource Educational Games

    Legit dude, that's a really good idea.
  5. Yeah, a lot of the risk of the reduced keyspace in this scenario is mitigated by having a limited validity window on the access token, so for your use-case, a shorter key should be secure enough. I'd reconsider just using an access token over 2-factor auth for a couple of reasons however; the spamming problem goes away when you authenticate initially with a password requiring an password prevents unauthorized access when the token transport (email, sms) has been compromised you can allow access to the real account owner in the same event, and allow the token delivery address to be changed if required (i.e. if the device or email login is lost)
  6. So you've outlined how the user logs in the first time, but what about subsequent times after their account has been created? (i.e. after a reinstall or on a different device). Be sure keep in mind the added risk you take on by storing a mobile number, and the cost/complexity of sending the password keys over SMS (if that's what you go with). In-memory is a reasonable idea, but it won't scale horizontally if you need to increase the number of servers you use, or if your process crashes or server reboots. I'd also suggest you consider a random string key rather than GUIDs, sure they're long, but they have a limited character set (0-9a-f), standard pattern and fixed length. I've not done the numbers, but ff the top of my head likely an alphanumeric password with length 9-12 could even provide a larger keyspace than a full GUID. They're also a pain to copy over if you're unable to copy/paste the code. Hope that helps. n
  7. You're right, you definitely *don't* want to store the passwords. Or even temporary passwords. As mentioned, OAuth2 is a good way to hand off the responsibility but requires an interactive browser session for the user to confirm. So assuming you can't/don't want to leverage OAuth, and you want the user to log into your service directly, you'll have to learn about effective password hashing methodologies. This page has a great write-up on the process, potential pitfalls and how to do it correctly. https://crackstation.net/hashing-security.htm
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!