Tag Info

Hot answers tagged

28

As Phil stated, you can still use the card using its number (as you would do on-line). Also, some ATM machine won't accept the card if not able to read the magnetic strip. The best thing is to use a credit card: in that case you can block the payment and get a refund.


23

Yes, you can. On some places you can find a device called demagnetizer. Just run your card over it (or over a very strong magnet), and the magnetic track will be corrupted and you will only be able to use the chip part of the card.


14

Embossed letters are still present on CC to allow to quickly carbon-copy (literally) the card on paper. That's in the (very) old days, but still allowed today, and it will count as PRESENTIAL. Magnetic strip is still there because half of the CC readers still work that way. ATM and TPV outside USA and UE are still missing the chip reader, and even inside ...


11

YES, but there is a big chance that an (internally chip-capable) ATM (depending on region) will reject the card! The most common 2 problems for an ATM (including chip-capable) to reject a card are: a dirty or scratched magstripe (as shown in spork's answer) an erased or mangled (=invalid) magstripe by exposure to magnets or EMP (they need to emit ...


8

Don't do this, it will not work in ATM machines in my experience. I've had to get a new debit card mailed in last month because there was a little scratch out of the magnetic strip, although I had not noticed and had used it for daily chip-only and wireless transactions. It wouldn't work in any (Dutch) ATM machine afterwards (I tried my own bank's and ...


8

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though. For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your ...


4

To ensure only the user has the key for his IMAP-Account, you can save the login credentials in your session symmetrically encrypted by a key, that is stored in a cookie. So the user can unlock the login credentials with his cookie, without that the webserver can't login. Of course you have to ensure that all occurrences of the credentials are overwritten ...


4

Since the author mentions his product is like Roundcube or Squirelmail.. I know how Roundcube works. Well, Roundcube's webmail DOES NOT have it's own method for logging in users. What I mean is that there is no database which stores anything about the user. Roundcubes takes the credentials user provided and puts them straight in imap_open(). If it ...


4

Encryption is used to provide confidentiality of data that may or will be accessed by an untrusted entity. Access control is used to limit or otherwise control an entity's access to an object. Asking "when do we use them" is an open question. Access controls can be anything from a padlock on a gate to a permission set on a filesystem. They can be simple or ...


4

Just to add on, _optout_ can be added anywhere in the SSID not necessarily at the end. However, Google's _nomap has to be placed at the end. Yes, 802.11x will networks will not be shared through WiFi sense. Official source: Microsoft WiFi sense FAQ. Look under "I'm concerned about sharing Wi‑Fi networks. Can you tell me a little more?" Theoretically, ...


3

I have seen systems that filter by a list of allowed IP addresses first, so in order to even attempt to use an authentication method you have to be coming from a specified IP address or range. This is similar to what you are describing. But in general, authorization refers to deciding what an authenticated user can do, and so logically comes after the ...


3

What I would say about the options that you outline is that HTTP Auth with SSL is a simpler but less flexible option and Oauth2 is more complex but has more flexibility in what you can achieve with it. One example, as you've noted in your ASCII art diagram, with OAuth2 it is possible to create a token which can be used in place of the password to ...


3

I think there is some confusion about the access token and how it is used which can cause a security problem. It is correct that the tokens can be a security risk, but this depends on the information you are asking for from the service. A friends list is more information than first and last name for instance, but that information is not as vital as personal ...


3

There were other (non tape-related) types of copy-protection as well. I remember one game in particular called ACE that had the Lenslok copy-protection: https://en.wikipedia.org/wiki/Lenslok From Wikipedia: "The Lenslok device was essentially a row of prisms arranged vertically in a plastic holder. Before the game started, a two-letter code was displayed on ...


3

Encryption mechanisms can be used to achieve specific outcomes: Making some data illegible, with the ability for specific individuals to retransform it into a legible format later: this can be used to implement confidentiality within some technical limitations Providing an authentic signature related to a specific blob of data: this can be used to provide ...


2

If you live in an area where no ATM and other cash terminal needs the magnetic strip, you can use a strong magnet to scramble the magnet strip. I personally have done this using a recycled neodymium magnet out of a decommissioned hard drive. Note: never put your debit card in a microwave if you intend to use it afterwards.


2

The registrar verifies the identity of the user (in a comment you said that the user is not anonymous towards the registrar). Identification means that each user has some kind of unique identifier. That could be their social security number, their real name + birthday + birthplace or something like that. The registrar uses a cryptographically secure hash ...


2

OAuth is an authorisation protocol, providing a way to give authorisation to access a protected resource. A by-product of the authorisation process is that the user is authenticated. Technically, OAuth does not have to give you any information about the user. What it provides is a validation that the user has given authority to the application to access ...


2

Certificates establish authentication (tying a person to an identity), which is the wrong approach to limit access to b.example.com - a user is still themselves on both sites, and all authentication's concerned with is having them prove their identity. Limiting access is authorization, which you should do on your end by actually checking the ID contained in ...


2

Protecting the root account makes cleanup much easier: if an attacker can't tamper with the kernel or most of the programs, it's much harder to hide malicious code. It also means they can't tamper with the antivirus and other protection systems.


2

In many cases the merchant can check the amount before shipping the item. However many payment gateways implement a checksum value that is hashed with a secret key and if the hash don't match the value the transaction is aborted. There are several flaws with this approach, I gave a presentation at blackhat asia last year that illustrate some of them. You can ...


2

Generally, one time use tokens are used to mitigate replay attacks and to make it harder to steal authentication information. They have other uses in protocol design for multi-tentant and multi-user systems. I am going to assume those don't apply because you said this was a custom API built just for you. If you are calling the API over the web using ...


2

To quote directly: Only use inbuilt session management. Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies. What this is saying is that, if you've got a secondary system which doesn't/can't use inbuilt sessions, you shouldn't send that second session token as a ...


2

The OpenSSH format is unsurprisingly supported by OpenSSH tools. (The OpenSSH public-key format, used in authorized_keys and with a prefix added in known_hosts, isn't itself a "de jure" standard, but is a trivial modification of a public-key encoding within the SSH2 protocol which is standardized.) Less obviously, OpenSSH uses OpenSSL format(s) for private ...


1

If an OAuth 2.0 token is compromised, you only need to concern yourself for the TTL of the token. If an HTTP Basic Auth header is compromised, the credentials do not expire. You would manually need to change your client_id and secret, and that's if you even knew or thought they were compromised. And it's likely you would need to change your client code ...


1

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective. Keep in mind, also, that SQL injection potentially does ...


1

I think it is fine to have a web facing panel as long as: Its not guessable, for example, www.example.com/admin. U don't want notorious users to attempt brute-forcing for two reasons: Incase the brute-force succeeds. If u have an account lockout policy in place, which you should, u don't want to be locked out by notorious users. Use strong passwords ...


1

You can achieve your goals with two methods: offload logic into servers controlled by you. Lots of games do this already. obfuscate your code. You can use XFuscator, for example. However, with 2, its impossible to be 100% secure. Preventing people from actually running your code by themselfes and not a server is actually quite impossible.


1

ive been thinking about this for a bit due to the fact that you should never store user passwords in plaintext. so I have came up with a possible solution for you. When a user signs up for a new 'service' to their account (e.g. they add gmail or yahoo, etc. ) what you are going to have to do is: Ask the user for their site password again (and validate ...


1

Look into the process of OAuth for client-side applications. Your OAuth flow should look something like this: User logs in Your API returns an access token for that user Your desktop application stores the user token Future requests send the token, and the API uses it to authenticate the user You cannot realistically protect a global secret key in your ...



Only top voted, non community-wiki answers of a minimum length are eligible