Posts by kasperd@westergaard.social
(DIR) Post #AbyiXHWuunBgt6wg6q by kasperd@westergaard.social
2023-11-19T15:10:17.238044Z
0 likes, 0 repeats
Which "freeloader problem" is it they are trying to solve?
(DIR) Post #Acywlg4LvZoQISPt7w by kasperd@westergaard.social
2023-12-19T22:47:35.647136Z
0 likes, 0 repeats
I think a better approach when rotating a host or user key would be to generate a certificate which contains the new public key signed using the old private key.When presented with such a certificate the known_hosts or authorized_keys file could be automatically updated. By replacing the old public key with the new public key in all places where it is found.
(DIR) Post #Acz5ZzakPuHSxP4Wau by kasperd@westergaard.social
2023-12-20T00:30:25.754219Z
0 likes, 0 repeats
I didn't know about that feature. It's not exactly the way I would have done it. It sounds like it's better than nothing, but I see a drawback in the way it's done.If you generate a new key because of a compromise you want to minimize the duration for which clients will keep accepting the old key.With my approach a client would only accept the old key next time they connect and never again after that. That means there is not really any drawback of still having the old key on the server. Having the old private key doesn't increase the risk of a leak if it was leaked already.With the actual approach clients would first have to connect once after the leak to acquire the new key and once all (or sufficiently many) clients have connected the old key can be removed. And then the clients have to connect again in order to remove the old key. So no sooner than the third connection would any client be able to reject the old key. And since clients connect at different intervals it would actually be much worse than that.What their approach is really missing is for the server to prove that it holds the old key but simultaneously tell the client that it is not to be trusted anymore.
(DIR) Post #Acz82Fr7jySlPrKtii by kasperd@westergaard.social
2023-12-20T01:04:09.738030Z
0 likes, 0 repeats
But certificates introduces a different private key. What are you going to do if that one was leaked?Sure when the client switches from old to new key the server needs to prove that it holds both keys. I never challenged that conclusion.What I am saying is a problem is that the server was presenting both keys as interchangeable without any indication that one is deprecated and should be removed from known_hosts immediately.
(DIR) Post #Ai6oMuVmUPKwEXVO7M by kasperd@westergaard.social
2024-05-03T08:20:10.006528Z
0 likes, 0 repeats
Instead of the option to say "Yes" they could give you three options:I am calling the bankI received a call from the bankI am not on the phone with the bankMight not be foolproof either, it's difficult to predict how social engineering attacks would adapt to that.
(DIR) Post #AjkFwTNvIiY6psosDI by kasperd@westergaard.social
2024-07-06T22:46:27.518204Z
1 likes, 0 repeats
So copying all of the data gets you a copy of the data, and you regard that as a vulnerability? And you are concerned that running a script as your user can do what your user can do?All of this sounds as expected. No application can be any more secure than the environment you run it in.The protocol could of course have been designed in such a way that some of the keys used are one-time keys. That could have exposed such cloning. But that would add complexity and potentially make backups of your data useless.
(DIR) Post #AnGqJX2HnaH2e1lyxk by kasperd@westergaard.social
2024-10-21T20:34:23.348989Z
1 likes, 0 repeats
IPv6 is simpler than IPv4. If you run everything as IPv6 it's so nice to work with.The only hard problem you will face is people who refuse do do IPv6, and suddenly you end up with a load of crap to work around lack of IPv6 and shortcomings of IPv4.IPv6 is not to blame for those problems as they only show up where IPv6 is missing.