Thats cool - I guess what I need to do is get on over to you board and login. :P I'll do that sometime in the near future. Cheers.
Maybe some day someone will come up with a cross-BBS login thing, like
how various sites use Facebook/google/Github/whatever to login rather
than requiring sign-up info.
Maybe some day someone will come up with a cross-BBS login thing,
like how various sites use Facebook/google/Github/whatever to login
rather than requiring sign-up info.
HOW do those systems work? If site X offers sign-in with Google/FB/ and you choose Google, does site Xy use your Google un and pw?
But then what happens if there is a security breach at site X? Will the hackers have access to your Google account?
HOW do those systems work? If site X offers sign-in with Google/FB/ and you choose Google, does site Xy use your Google un and pw?
Maybe some day someone will come up with a cross-BBS login thing, like how various sites use Facebook/google/Github/whatever to login rather than requiring sign-up info.
Now *that* is a spectacular idea.
HOW do those systems work? If site X offers sign-in with Google/FB/ and you choose Google, does site Xy use your Google un and pw?
But then what happens if there is a security breach at site X? Will the hackers have access to your Google account?
Perhaps start with a communal FSX login system?Maybe some day someone will come up with a cross-BBS login
thing, like how various sites use
Facebook/google/Github/whatever to login rather than requiring
sign-up info.
It is, but will it be a pain like FB where some registers your nick? And do you lose the I'm fred@somebbs not fred@xbbs...
In BBSing world, I cant imagine how this could happen, since we use a terminal software, which by definition is a direct connection.
The BBS software could make the backend connection to get/validate your credentials while you are logging on I guess...
I'm actually after a federated authentication system - but cant think
how to make it, within the constraints of BBSing.
Hello Adept!hackers h
** On Wednesday 29.07.20 - 18:54, Adept wrote to paulie420:
Maybe some day someone will come up with a cross-BBS login thing,
like how various sites use Facebook/google/Github/whatever to login rather than requiring sign-up info.
HOW do those systems work? If site X offers sign-in with Google/FB/ and
you choose Google, does site Xy use your Google un and pw?
But then what happens if there is a security breach at site X? Will the
access to your Google account?
The only super problem I can forsee, is that you won't have httpredirection available to you. So
you'd probably have to ask for user/pass in the normal sense on the hostsystem and then ask if its
right or not...
I think you'd have to write a front end to replace the login, or in thecase of the old DOS system
probably a logon door. I guess most of the others can, but super allowsyou to tell it who is
Adept wrote to paulie420 <=-
Maybe some day someone will come up with a cross-BBS login thing, like
how various sites use Facebook/google/Github/whatever to login rather
than requiring sign-up info.
Andre wrote to alterego <=-
On 30 Jul 2020, alterego said the following...
In BBSing world, I cant imagine how this could happen, since we use a terminal software, which by definition is a direct connection.
The BBS software could make the backend connection to get/validate your credentials while you are logging on I guess...
That's what I was initially thinking. But now that you mention it I
can't think of a way to send the user over to authorize the request
within the terminal, much less grab the token and give it back to the
BBS.
arelorhorses.com asks techgiant.com if this user has been authed with techgiant.com. techgiant.com verifies that the user has an account
with them (say, via a password prompt or whatever) and tells arelorhorses.com "That's right, this user sold their soul to us,
give him access as user DumbUser".
Center of Awareness did that for a while - it is(was) a Synchronet
service that did real-time messaging (chat and message echoes) and at
one point shared user databases, so you could login on any of the CoA BBSes with a common username/password.
Some people panicked over the notion of sharing BBS info. I think the issue was with sysops whose board you don't log into having your login info, like we'd log in as a user and post untruths, or something.
What about utilizing SQRL:
https://www.grc.com/sqrl/sqrl.htm
echicken wrote to poindexter FORTRAN <=-
I'd like to redo it from scratch some day, but then I have a lot of
things I'd like to do and not enough time or energy.
I had wanted the shared user database to be an opt-in system and was pretty uncomfortable with it from early on. The counter-argument was
"it's just a BBS thing and nobody cares".
The shared-users thing died a quick death, because I wasn't the only
one with reservations about it. I was pretty happy to see it go.
There's merit in the idea, but it should be done properly, with some semblance of security and respect for privacy. Probably a bit easier to
do today than ten years ago.
Maybe some day someone will come up with a cross-BBS login thing,
like how various sites use Facebook/google/Github/whatever to
login rather than requiring sign-up info.
HOW do those systems work? [snip]
I think most work like this:
The user arrives at arelorhorses.com, and clicks on Authenticate Via Tech Giant.
arelorhorses.com asks techgiant.com if this user has been authed with techgiant.com. techgiant.com verifies that the user has an account with them (say, via a password prompt or whatever) and tells arelorhorses.com "That's right, this user sold their soul to us, give him access as user DumbUser".
TechThe user arrives at arelorhorses.com, and clicks on Authenticate Via
Giant.
arelorhorses.com asks techgiant.com if this user has been authed with techgiant.com. techgiant.com verifies that the user has an account with them (say, via a password prompt or whatever) and tells arelorhorses.com "That's right, this user sold their soul to us, give him access as user DumbUser".
But what is the tradeoff or benefit to arelorhorses.com to do this? Is there a payola model or promise to provide tracking info behind this?
Hello Arelor!
** On Thursday 30.07.20 - 06:02, Arelor wrote to Ogg:
Maybe some day someone will come up with a cross-BBS login thing,
like how various sites use Facebook/google/Github/whatever to
login rather than requiring sign-up info.
HOW do those systems work? [snip]
I think most work like this:
The user arrives at arelorhorses.com, and clicks on Authenticate Via Tec Giant.
arelorhorses.com asks techgiant.com if this user has been authed with techgiant.com. techgiant.com verifies that the user has an account with them (say, via a password prompt or whatever) and tells arelorhorses.com "That's right, this user sold their soul to us, give him access as user DumbUser".
But what is the tradeoff or benefit to arelorhorses.com to do this? Is there a payola model or promise to provide tracking info behind this?
What about utilizing SQRL:
https://www.grc.com/sqrl/sqrl.htm
I've not heard of Steve Gibson before
but it seems he also has a strong negative following - havent formed an opinion as to whether that is justified yet (not really my area of expertise).
What about utilizing SQRL:
https://www.grc.com/sqrl/sqrl.htm
I've not heard of Steve Gibson before - but it seems he also has a strong negative following - havent formed an opinion as to whether that is justified yet (not really my area of expertise).
I used to frequently listen to his Security Now podcast on Twit. I
looked up some of the complaints and they look pretty dated although I
can understand it can be hard to get a bad taste out of your mouth.
I believe the SQRL is an ingenius solution no matter who came up with it.
I really am a enthusiastic supporter of gpg encryption. The original author of pgp, Phil Zimmerman used to be a hero of mine until I met him in person. . I do not care for him a person however I wont let that get in the way of using a good tool.
I did not realize he was still around.
Ogg wrote to nristen <=-
I really am a enthusiastic supporter of gpg encryption. The original author of pgp, Phil Zimmerman used to be a hero of mine until I met him in person. . I do not care for him a person however I wont let that get in the way of using a good tool.
What happened? Maybe there was something wrong with you! LOL.
I did not realize he was still around.
I looked up some of the complaints too. Much ado about nothing.
But I don't know if people even _use_ SpinRite at this point.
Yeah, that's the biggest red flag that I see. I'm in the InfoSec industry, and literally zero of the well-respected researchers, penetration testers, or leaders pay any attention to him. That's pretty damning to me.
But I don't know if people even _use_ SpinRite at this point.
Yeah, that's the biggest red flag that I see. I'm in the InfoSec
industry, and literally zero of the well-respected researchers,
penetration testers, or leaders pay any attention to him. That's
pretty damning to me.
I'm not in that industry, but I'm curious - what's the view of his SQRL
by the InfoSec industry?
For the most part, he seems to be a very private guy and doesn't engage
in big-shot conventions, sales galas, or news interviews to push his expertise or products. It's hard to pay attent to someone like that.
Steve was the first to discover that Sony was including a rookit on some audio CDs that installed on people's PCs when people accessed the multimedia features of the CD. He was very thorough in his evidence and technical knowledge.
can't find anyone who's even commented on it. When I look at it, there are so many flaws with it that it's not worth writing a novel about. Too hard for end users to use, to easy to MITM and/or fabricate QR codes, requires end users to make sure the domain is the right one (which we exploit in phishing all the time), and so on.
even know anyone that takes Gibson or Security Now seriously. He's just not a respected individual.
Is Bruce Schneier still a respected individual in the community? I think that's the only security person that I follow remotely regularly.
I'm interested to understand those flaws a little better. I will admit
The MITM comment - the videos I've been watching of Steve I thought addressed this - I'm keen to know how it can be exploited?
(I will admit, I'm surprised it hasnt had greater adoption - but then
you might enlighten me... :)
Andre wrote to alterego <=-
On 05 Aug 2020, alterego said the following...
It's written like an known-bugs comment. The problem is that method
makes up the majority of how MFA is currently done. You use a second device, usually a phone, to authenticate the first device, usually a laptop. So a simple password spamming attack to find valid accounts,
then pummel the hell out of those working accounts so that users get endless MFA requests until they get annoyed enough to just say, "fine,
I approve" on the phone. SQRL in that case would be sending it to the actual website directly, and the attacker is authenticated.
It's a real-world attack that works. We do it all the time.
The whole system is just so out of touch with how end users actually operate, and there are so many issues from just my cursory glances, that it'd take forever to pick them all apart. I've seen some websites/blogs that try, and do okay with the simpler bits.
It's a real-world attack that works. We do it all the time.
simple password spamming attack to find valid accounts, then pummel the The point I'm trying to make is not that the attack is unique to SQRL. Any hell out of those working accounts so that users get endless MFA requests until they get annoyed enough to just say, "fine, I approve" on the phone. SQRL in that case would be sending it to the actual website directly, and the attacker is authenticated.
SQRL doesn't work anything like Microsoft Authenticator or Duo, the apps don't do push
notifications at all.
The browser plug-in only springs to life if you click a sqrl:// URL.
A user knows they want to log into a website, the go to the logon page
to get a generated
QR code, the user then has to open the app on their phone, point their camera at
the QR code and they're logged in using the method described above.
No, I wasn't saying it was, but I can see how my analogy would make it look that way. My point wasn't about how you deliver the fake QR code, just that it's possible to serve up codes to enough people that by sheer numbers someone is going to approve it. Directed attacks are rarely
Browser plug-in? That's a nonstarter. We're in PGP world of difficulty now. This isn't feasible for organizations to roll out or for consumers to use. It's too difficult.
Your points are all valid. But my point is simply that this isn't any more secure than existing methods, and in some cases worse, and that it's
The QR Code on its own is for all intesive purposes useless, unless it has started the "auth process".
So if "x" number of people captured the same QR code that I'm using to login to a site - it wont generate an "approve this alerts" to me. Even
if the QR Code was a start of a cycle that generated an "ask message" -
I dont get asked that message until I have successfully completed the authorisation cycle - so the "x" people wouldnt even get throught that
to generate that "approve this" message intended for me.
I'm not sure I agree with you on this point. Yes, its a little "more" setup than normal - and since it is (for all intensive purposes) a one time activity that I might forget how to do it - I dont think it is that difficult.
Why can't the attacker, who already has your valid user/pass start the process of requesting the QR code and deliver it to you to approve?
Password/MFAtoken resets and unlocks for infrequently used systems by far makes up the majority of tickets. People are busy with their actual job,
What about utilizing SQRL:
https://www.grc.com/sqrl/sqrl.htm
The tradeoff is arelorhorses.com no longer has to store credential
data directlÃy. When you are a mass service catering to the dumb
masses, emails from people telling you they forgot their password of
their user name can really drag you down. You can outsource all that
crap to a third party.
Seriously, there is a lot of people advocating for 2FA in web
services, but that people is usually not the people who has to reauth
users after their break their secodn factor device. It brings such an administrative overhead. Some administrators actually bill you a fee
if they have to restore your access too often, it is that bad.
The idea is that users will sign in because they don't have to make
yet another internet account with yet another password to remember.
Also, arelorhorses.com don't have to store password data, so if they
get hacked at least the hackers wont get your password.
Of course if tech giant gets hacked, then you're stuffed.
I remember participating in the "Login with Google/Facebook" options for passwords to create and remember!" Now I regret it. I don't remember what sites had that, but they were temporary and unimportant places
I always wondered why isn't there something like a PGP private/public
key thing for a login process. SQRL mentioned earlier is along those lines.
(Might need to give it a few days - while the SQRL completes, I havent actually written the "login to SBBS" bit yet :)
(Might need to give it a few days - while the SQRL completes, I havent
actually written the "login to SBBS" bit yet :)
So I've got it working.
Its pretty cool logging into the BBS by using the app on my phone! Call it a fusion of 1980 and 2020 :)
I thought SQRL had a non-phone option too.
Absolutely! Why not produce a short YT video of the process.
I thought SQRL had a non-phone option too.
Yeah it does - there are browser extensions for SQRL - but they work by responding to OS sqrl:// links (normally on webpages).
I posted something in the Synchronet Facebook page...
Yeah it does - there are browser extensions for SQRL - but theyI suppose that method can be a spoofing vulnerability?
work by responding to OS sqrl:// links (normally on webpages).
It's kinda magical how the phone can log you in. I'm missing how
that actually works.
You should send out a heads up to Gibson. I think he would be
tickled to see an implementation of (20th century) SQRL with
(19th century) BBS technology.
Yeah it does - there are browser extensions for SQRL - but they work b responding to OS sqrl:// links (normally on webpages).
I suppose that method can be a spoofing vulnerability?
You should send out a heads up to Gibson. I think he would be
tickled to see an implementation of (20th century) SQRL with
(19th century) BBS technology.
I suppose that method can be a spoofing vulnerability?
I suppose if you downloaded a malicious "sqrl" client that
took over as the sqrl:// handler & leaked your private key
after you unlock it, that could be one method of attack.
You should send out a heads up to Gibson. I think he
would be tickled to see an implementation of (20th
century) SQRL with (19th century) BBS technology.
You'd HAVE to imagine Steve was a BBS user back in the day.
With his reluctance to moving to new technology I'm
actually a bit surprised he's never mentioned BBSes on the
show.
Yeah it does - there are browser extensions for SQRL -
but they work by responding to OS sqrl:// links (normally
on webpages).
I suppose that method can be a spoofing vulnerability?
I dont believe so - can you explain more?
Nevermind. I have to review the implementation and mechanism
more closely again before I comment further. But on one of his SQRL-presentations, there was a question from the audience
asking what if the sqrl:// link did not match what was
expected... and Steve's answer was "Then don't authorize it."
That seemed to be an open door for a scammer, especially when
our muscle memory would instinctively click right away - BEFORE
we even realize that we clicked on a bogus sqrl:// link to
authorize or register with a site for the first time.
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 28 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 35:24:13 |
| Calls: | 2,013 |
| Calls today: | 3 |
| Files: | 11,119 |
| Messages: | 944,259 |