First, is there any way people can think of to enable 2FA?
Second, what about email verification to enable auto-upgrading of user accounts from, say, s10 to s25?
Third, is there some kind of ACS code for determining if a user is
logged in via telnet or ssh? Telnet is delivered as plaintext, and ssh
Fourth, is it possible to detect logins via a websocket and disable file transfers? Is there some kind of ACS code? Is it even possible to detect?
What would be the circumstances that you feel should trigger a multi-factor authentication chain? A change in IP or something? If we could define what I feel is a reasonable workflow then maybe I would
make this an option. But forcing a MFA every time a user logs in is overkill and I don't want that to be a function.
Second, what about email verification to enable auto-upgrading of use accounts from, say, s10 to s25?
This has/can been done in MPL/Python but its on the list to enabled internally once the outbound SMTP queue is enabled. The hold up on that is some indecisiveness in how I want to implement it and a lack of time
to experiment.
Third, is there some kind of ACS code for determining if a user is logged in via telnet or ssh? Telnet is delivered as plaintext, and ss
No there isn't, but I just added one based on your suggestion :)
The next build will have "os" ACS which will be TRUE if the user is
logged in via a secure connection (in this case only SSH falls into that category). Do you think "OS" also return true if the user is logged in locally or only via SSH or any other encrypted protocol?
Fourth, is it possible to detect logins via a websocket and disable f transfers? Is there some kind of ACS code? Is it even possible to det
I don't know enough about this to comment :(
First, is there any way people can think of to enable 2FA?
Second, what about email verification to enable auto-upgrading of user accounts from, say, s10 to s25?
Third, is there some kind of ACS code for determining if a user is logged in via telnet or ssh? Telnet is delivered as plaintext, and ssh is preferable when transfering some files or communicating on message nets that expect some degree of privacy. I'd love to lock down certain message and file areas to ssh-only connections. Think of like s25g5 for security level 25, message group 5, but I'd like to add something on there to make it only visible during ssh connections.
Second, what about email verification to enable auto-upgrading of user accounts from, say, s10 to s25?
category). Do you think "OS" also return true if the user is logged in locally or only via SSH or any other encrypted protocol?
First, is there any way people can think of to enable 2FA?
I can't answer any of these for Mystic, but for ENiG, but they could be applied to Mystic (possibly with some code from g00r00 or MPL?)
You can use Google's 2FA for example, as a 2-auth login. In ENiG this
can be done with a .js mod @ login seq, and I imagine the same applies
to Mystic with MPL.
FWIW there is something similar in ENiG. The ACS code 'SC' determines if the connection is considered secure. This is enabled for SSH and secure WebSocket currently.
Right now, I'm writing a mystic python script to allow users to confirm email and phone # as password recovery options. It's pretty hacky...enabling postfix requires a slew of other configuration considerations outside the scope of mystic.
I'm curious what is in the enig js for doing this :)
Callback verification was pretty solid in years gone by since it
typically wasn't trivial to change your phone number. Even if you had to carefully blacklist emergency services to combat cheeky applicants...
On 12/30/17, esc said the following...
Second, what about email verification to enable auto-upgrading of user accounts from, say, s10 to s25?
Many systems already do this via numerous different email verification doors >or scripts, though with all the free email services out there I'm skeptical >about how useful this is.
Callback verification was pretty solid in years gone by since it typically >wasn't trivial to change your phone number. Even if you had to carefully >blacklist emergency services to combat cheeky applicants...
--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)
I'm going to be the guy that everyone hates here in this reply:
Why in the world does a BBS need 2fa? We are storing no personal information, >and to be honest everything in the bbs is nothing that can't be sent >plaintext to begin with.
I work in cyber security. One of the main ideas is you don't build in >controls just to do so. That causes you and the users more pain. More >security - less flexibility. I honestly see no valid reason to build in >advanced security controls for a bbs. And a
I think your security you have is fine. And I think there are a lot of other >things folks would like to see mystic have and issues to be fixed than to add >in 2fa that is really going to be useless and annoy users.
For anyone who is going to think this post is completely wrong, point out one >piece of information a normal bbs collects that would hurt a user if it were >obtained through a hack. And email is not considered PII. The only thing I >can think of is address,
If we start collecting SSNs, credit card info, and other info, you have my >support.
I hate to see bloating mystic for the sake of adding features that are just >"cool".
On 19:43 30/12 , Static wrote:
On 12/30/17, esc said the following...
Second, what about email verification to enable auto-upgrading of user >> es> accounts from, say, s10 to s25?
Many systems already do this via numerous different email verification doors >>or scripts, though with all the free email services out there I'm skeptical >>about how useful this is.
Callback verification was pretty solid in years gone by since it typically >>wasn't trivial to change your phone number. Even if you had to carefully >>blacklist emergency services to combat cheeky applicants...
--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)
--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader
--- Mystic BBS/NNTP v1.12 A37 2017/12/30 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)
if it was ld you hope the verification works fast lol
I agree that 2FA would be overkill in most circumstances, but it'd be
cool to have the option. I'm working on doing it locally just for fun
for things like password resets. Give the user an option to confirm an email address and phone number, and then a password reset can be
You can use Google's 2FA for example, as a 2-auth login. In ENiG this
can be done with a .js mod @ login seq, and I imagine the same applies
to Mystic with MPL.
Why in the world does a BBS need 2fa? We are storing no personal information, and to be honest everything in the bbs is nothing that
can't be sent plaintext to begin with.
And to take it one step further in this thinking:
2FA concept is really meant for systems that need granted or privileged access to a part or entire access of a system that is generally not a public facing or openly accessible site. I have almost never see. It implemented in the public realm.
Right now, my socket policy server detects wss:// connections and forwards those to telnet. How on earth could I pass a secure connection to mystic? Any ideas here? :)
2FA concept is really meant for systems that need granted or privileged access to a part or entire access of a system that is generally not a public facing or openly accessible site. I have almost never see. It implemented in the public realm.
Why in the world does a BBS need 2fa? We are storing no personal information, and to be honest everything in the bbs is nothing that
can't be sent plaintext to begin with.
For my purposes, to automatically validate a user (similar to CBV) or for >automated password recovery.
--- Mystic BBS v1.12 A37 2017/12/27 (Linux/32)
* Origin: lo fidelity bbs (21:2/142)
And to take it one step further in this thinking:
2FA concept is really meant for systems that need granted or privileged access to a part or entire access of a system that is generally not a public facing or openly accessible site. I have almost never see. It implemented in the public realm.
I also am toying with the idea of implementing it on my own account. :)
--- Mystic BBS v1.12 A37 2017/12/27 (Linux/32)
* Origin: lo fidelity bbs (21:2/142)
On Sunday, December 31st Nugax was heard saying...
2FA concept is really meant for systems that need granted or privileged access to a part or entire access of a system that is generally not a public facing or openly accessible site. I have almost never see. It implemented in the public realm.
This simply isn't true. 2FA is used heavily in the public by "normal" users. >Games, game portals (e.g. Steam), email accounts, Google, FB, MS, ...a just >tons of "site" logins, and so on.
2FA exists such that you have another "something you have". I can't simply >guess/steal your password and get into your account - I need your 2FA device in
hand as well.
BBS's have all sorts of PII. Accounts often have name, email, DOB, location, >phone number.
2FA login doesn't make a ton of sense yet, but if a system can be set up to >only allow secure (SSH, wss://, ...) logins as well, it starts to make more >sense. Further work needs done to create message networks and the like that are
not being sent plain-text all over the place.
2FA for a password recovery isn't too bad. Email recovery of course makes >sense. SMS also makes sense.
I think most of the discussion here for Mystic anyway has been that it can all >be achieved by MPL/Python, and I'm positive g00r00 is smart enough to >prioritize the important stuff over this type of thing :)
--- ENiGMA 1/2 v0.0.8-alpha (linux; x64; 6.11.3)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
I just don't see the need guys. Waste of time, in my opinion you didn't ask for lol.
Don't kick me out the mystic club guys :)
I disagree. 2fa on steam and stuff is because you have payment and account info which becomes PII. Email isn't PII. Neither is name without other identifying info. Address and dob are but let's be honest, most Folks don't provide info to a bbs willingly with anything that can be stolen if even true. I don't even ask PII. Maybe dob, but nothing else.
I do cyber assessments daily, I think a bbs system is not a place where a lot Of threat exists for data leaks to where you need to implement controls such as 2fa. Want to add it as an option, fine. But, I bet almost no one uses it. Secure communication like ssh and encryption is a better route.
g00r00 wrote to esc <=-
The next build will have "os" ACS which will be TRUE if the user is
logged in via a secure connection (in this case only SSH falls into
that category). Do you think "OS" also return true if the user is
logged in locally or only via SSH or any other encrypted protocol?
Right now, my socket policy server detects wss:// connections and
forwards those to telnet. How on earth could I pass a secure connection
to mystic? Any ideas here? :)
Hmmm... For ENiG it's slighty differnet in that it handles WebSocket natively, so no telnet in the mix in this case.
You might be able to implement a "secret knock" or something to indicate on the Mystic side that the connection is from a secure channel? Not the best, but with Telnet it's limited. What I mean by this is you'd
establish a Telent connection then send a special string that only your (proxy) system should know. Maybe a MPL could pick that up and set a bit somewhere?
I think most of the discussion here for Mystic anyway has been that it
can all be achieved by MPL/Python, and I'm positive g00r00 is smart
enough to prioritize the important stuff over this type of thing :)
Still, implementing a validation system is fine, that's not classic 2fa
as was discussed. And
Email validation is cool, and I'd use that, but making users go through 2fa every time you login is overkill and useless for a bbs. I swear no
one is trying to snoop on your usurper game or echomail that's on every bbs system out there. Lol
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 31 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 203:41:18 |
| Calls: | 2,083 |
| Calls today: | 1 |
| Files: | 11,139 |
| Messages: | 948,001 |