Tag Info

New answers tagged

0

"Should I worry about this?" No. "Does this algorithm have any other obvious potential weaknesses?" It releases "a hash (or HMAC) of the HMAC key", relies on trusted timestamping, and allows an attacker to exchange "the message she wants to publish" with "the hash of the replacement HMAC key". "Otherwise, what are the implications of publicly sharing ...


0

The whole point in having a known_hosts is to keep a record of keys associated with the host they belong to. To be more specifically, it records the key associated with the hostname you tried to connect to with the ssh, scp or sftp command. It will help you avoid MITM attacks, since any SSH-based command will alert you if the server key has changed since it ...


1

Stick to your instincts Jake... this most definitely isn't 2FA. What you've described is actually two-step verification, as the OTP via email (or SMS for that matter) isn't considered "something you have" and isn't therefore a second factor. Here's a flow diagram to help you. Source: ...


2

With your proposed system, anyone who intercepts the login transaction can store a copy of the password hash and use it in place of the password to impersonate the user. If you really can't use SSL to protect communication, look into challenge-based authentication systems, where the password is never transmitted over the network, but instead proof that the ...


0

Verification is the act of proving your identity. Authentication is the act of proving you are the same person as before, without necessarily knowing who that person is. re: Biometrics, I think the confusion comes down to the nature of biometrics. A username/password (something you know) says nothing about who you are. The same is true of a hardware token ...


0

Here's a flow diagram explaining the differences. Source: https://ramblingrant.co.uk/the-difference-between-two-factor-and-two-step-authentication


0

As pointed out by apsillers in the comment, what you are seeing are multiple TCP connections from the same IP address. If you group the source port numbers, you will be able to see that each connection is making a login attempt at a maximum rate of one per two seconds: 5967 Sep 7 11:50:20 .... sshd[13755]: Failed .... from 122.225.103.125 port 32582 ssh2 ...


0

You don't need to crawl through ALL combinations - you just need to find ONE that you are not authorized to access. That proves the method is broken. Because it is an MD5 hash, it is also likely the same length each time, which makes it easier to narrow in on a valid link. I believe that a crawler would take less than about 5 lines of code, and less than ...


2

There are a couple of issues to consider with "secret" URLs. First, they offer a different level of security against discovery when served over HTTP vs. HTTPS. Over HTTPS, the path is protected. Over HTTP, it is not. This means that when using HTTP, anyone in the path of the traffic (people sniffing wireless traffic, proxy servers, caching servers) ...


0

Devices like Yubi Key have been trying to accomplish this. The underlying problem is that it is a single factor, and if lost, exposes a major risk to the user. Matching with biometrics is also a promising field, but the technology isn't ready yet. Anything you measure for biometrics can change over time because a body changes over time. There was a ...


6

The security of your randomly generated 15 characters password depends very much on how it is stored on the system that is being breached. If the system stored it in clear text, your password would be stolen in 0s. Assuming the next worse case scenario of your password being stored as an MD5 character that is being hashed just once, without salt, if there ...


1

I use a password manager and use passwords of length 22 (why 22?) or however long they'll let me. (My bank only allows up to 15, sekeritah yay) Do I worry when I hear that a site that I use had a data center breach? No, I don't worry. That is a comfort of having a really strong password. Some hacker got their hands on my hash? Yeah sure, whatever, have fun ...


1

Firstly, and to be very clear, OAuth 2 is not an authentication protocol. If you wish to know the identity of the user, there are other protocols designed to solve this problem, such as OpenID Connect. If you intend to use OAuth 2 for the purpose of authorizing access to your protected resources, continue reading. To answer your direct question: you appear ...


0

@BadSkillz pretty much said it. Addendum To Part iv: You can use GRC's Interactive Brute Force Password “Search Space” Calculator to estimate how long it may take for a random password to be cracked. According to your scenario about 10 to 12 characters in lenght should suffice. But be cautious: This is based on a random brute force attack. If your password ...


2

i) No password is ever protected against ALL threats. If you write it down and someone steals your notes... ii) There could be, for too many different reasons. iii) Yes, depending on if the passwords are salted or not, cracking hashes is fairly easy. Without a salt on the password all you need to do is run it against rainbow tables. iv) Again, this ...


0

Sending a verification code is a good option to make use of the information that you have in the database. For the type of algorithm, you can use a complex or a simple ones. The simple one that I have in mind is the timestamp and add salting to it. Like how cryptography works. As for the expiry time, make it like 3 mins would be sufficient. The number of ...


3

Using the mobile phone as single authentication factor would be very bad. The mobile phone number is being used by gmail as the optional second-factor authentication The import part here is "second-factor". It sound like you are proposing to use the mobile as a single authentication factor. That would be very bad because mobile phone are not secure. If ...


14

In addition to the other points mentioned, another significant drawback to HTTP Basic Authentication (vs, say, forms-based login) is that it has no concept of "logging out". Once the user inputs their credentials, the browser stores them internally to send with every subsequent request. This means that you can't have a timeout or "Log out" button/link to end ...


10

Basic access authentication over HTTPS has clear advantages over Digest access authentication over HTTP. Even with digest access authentication, you can actually store your passwords hashed with an unique salt (realm + username), but first this salt is guessable (this makes attacks against single users and small groups easier), and second you can't use ...


33

Basic authentication has a number of drawbacks, one of which is that the username and password are passed in the clear with every request. This is clearly unsafe under HTTP, but is somewhat less vulnerable under HTTPS. However, because the credentials are submitted with every request, it's still worse than any other method (including digest) that does ...


2

This is how I understand it, please correct me if I've misinterpreted something. Sending Password in the Clear A one time risk is never worth it when it can be avoided. Using a secure algorithm like bcrypt or PBKDF2 with a salt does not require the password to be sent in the clear. Even if the password is sent under TLS, am I to trust that you're not ...


0

These are really two questions. How can I guarantee that requests from sources claiming to be this client application can be trusted? You can't. The specification says: The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client [...] The resource owner (aka. user) ...


0

This proposed security system is vulnerable to CWE-602: Client-Side enforcement of server-side security, and does not limit an attacker's ability to access this RESTful API. Fundamentally, any secret provided to the mobile app will be known by the attacker. An attacker with a jail-broken phone can observe memory used by any running process. It must be ...


1

There is no need to involve a certificate authority (CA), or trusted 3rd party, when you control client and the server. By avoiding the need to have a CA, you are no longer threatened by rogue certificate authorities, and rogue certificate authority certificates. Using two self-signed certificates it is possible to create a very strong TLS connection ...


0

Erasing or damaging the magnetic strip well stop it being read, this may prevent the card working in some ATMs and such. As pointed out card not present, contacted (this one is lethal) and using an old imprinter (if still allowed for use by merchant bank) are valid loopholes. However the EMV spec has a mode of doing a signature transaction without the PIN ...


0

Mount with exact UUID to different location. Backup to that location. Use blkid to get UUID. blkid /dev/sda1


0

If the hard drive is encrypted, you need the correct password to decrypt it before it can be mounted for data transfer. That, in itself, is a form of authentication. If you still need to verify the drive serial number, you can install smartmontools, then run the command (if your device is at sdb): # smartctl -i /dev/sdb smartctl 6.2 2014-07-16 r... ...


-2

One mitigation I didn't see mentioned is to add a Google reCAPTCHA (or similar). This will prevent "brute force" attempts which is what you're looking to address. Just make sure to perform the reCAPTCHA validation before validating the submitted credentials. Adding this functionality still allows one to perform timing attacks so long as they input the ...


2

Yes - this is a security threat. As others have pointed out, this is a side channel attack. Although you are following OWASP advice and returning the same message, you are still revealing to an attacker whether the particular account exists. If you were using user-selected names, I would say leave it be. In that case, the sign up process reveals what user ...


1

I don't know about the magnetic strip. I guess you can. In my country almost all shops have chip-readers. And if the card doesn't work, report it broken and you get a new one. CSC / CVV But what about the card security code (CSC or CVV). With your credit card number, expiration date and CSC anyone can shop online. No need to steal a card! It's just a ...


3

This is a type of timing attack, leading to a username enumeration vulnerability. Whether this is a threat or not depends on the design of your system. If usernames are supposed to be private them it is a concern. Some systems are written in such as way that the enumeration of users fits into the design, such as email providers, as email addresses are ...


1

Crime is said to be mostly opportunistic (by design researchers among others) so I'd assume getting hold of someone's fingers to be a rather harder opportunity to fulfill than getting hold of a key ring. In practice in all three scenarii there are limited options for attackers: Steal your auth factor Bypass the factor and force one's way in Piggyback you ...


0

Why not write "VOID" (or "CHIP & PIN ONLY") in big letters in the signature field on the card (and take a photo of it for your records)? That should only allow it to be used for chip and PIN transactions. If a merchant does allow it to be used for a signature transaction, then the merchant and bank are going to have a hard time justifying allowing the ...


2

I don't see this as a major threat. Yes, it gives an attacker a way to verify that a given username exists, but in a typical application, there are many other ways to get this information. If you want to prevent this timing attack, you can re-write your login page to hash the password before checking to see if the username exists, thus slowing down all ...


2

I agree this could be seen as something like a side channel attack. It could pose a significant threat, but it depends on the circumstances as most registration pages will tell you if an email is already registered. This could be an issue where users are assigned a random username such as a bank assigning a client ID. Just hash the supplied password ...


7

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 ...


1

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.


1

It's not a factor at all because a signature is not primarily an authentication mechanism. In a credit card transaction the possession of the physical card is used for authentication. A signature is primarily used to ensure there is no ambiguity about the intent of the person using the card. For example: A signature ensures there is no misunderstanding ...


19

This behaviour is specified by RFC2617. The reason for the extra round trip is that the server can request different kinds of authentication: basic, digest, etc. If you know in advance that the server takes basic authentication, then as you say, you can save a round trip. But that isn't the default, and I think the .NET libraries are right to expose this as ...


-2

You should mark all of your cards "see photo ID" in the signature block on back. If a merchant accepts a fraudulent transaction after you've done this, it's entirely on them.


6

The prime usage of signature is to signal intent. Properly verifying if some signature A 'matches' some signature B is something that requires a lengthy and costly expertise and generally isn't done outside of significant court cases, so in most cases it actually doesn't function as authentication factor at all. For example, when accepting credit cards at ...


1

You can use a cloud-based password manager and a USB dongle. This would be the safest and most convenient solution especially if your phone is unavailable. USB dongle can be strengthened with a code. The token serves as a "something you have" factor and the code is "something you know" just like with your credit card. The database of your login credentials ...


0

Funny, I think you're right about it being a biometric. But here's how it's better: If your signature is stolen, you can change it. When databases of fingerprints, vein and iris scans, etc start getting stolen, the biometric industry will have issues.


0

I am coming from your post from the null group. Glad you got almost closer to 0wn the system;) in sqlmap's parlance LEVEL could mean two things. I am responding to your edit on Sept 4 12.58. -v (1-6) is the verbosity level, which is used to output specify the amount of messages sqlmap spits to the screen. --level (1-5) is the sqli detected level. If the ...


10

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 ...


7

I would consider a physical signature a biometric, albeit a pretty weak one. It isn't really something you have, since unlike a physical token, it cannot be stolen, or given to another (or, under most common circumstances, lost). It isn't really something you know either, even if an attacker knows exactly what your signature looks like, he cannot necessarily ...


1

First rule to remember is that you don't perform tasks as root unless they have to be performed as root. This part reduces the risk of doing damage by a typo or other mistake. It also reduces the risk of damage if the tools you are using happen to have a security vulnerability. Additionally accounts should only have the privileges they need and nothing ...


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 ...


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.


2

OAuth is flexible, and sometimes the OAuth flow is modified for application specific needs. The most common two flows are 2-legged and 3-legged, which if these flows are implemented correctly, then they are generally accepted as secure. The proposed CORS AJAX implementation of the OAuth flow violates two security requirements of RFC-6749 - OAuth 2.0 ...



Top 50 recent answers are included